Overview
OAuth access scopes on GKE nodes are a legacy permission boundary. Google recommends managing access primarily with IAM roles on the node service account, and using custom scopes only when you have a specific reason to further restrict what client libraries and the gcloud CLI can request from a node.
Rationale
The main security decision is the node service account and its IAM roles. Broad scopes such as cloud-platform can still expand the usable surface for software running on nodes, especially if the attached service account is also broad. Review broad scopes together with the node service account, and prefer a dedicated least-privileged node service account plus Workload Identity Federation for workloads.
Remediation guidance
Current recommendation
Treat this control as a review point, not as a reason to blindly remove cloud-platform from every cluster. Google documents access scopes as legacy and recommends managing permissions with IAM. The highest-value fix is usually to replace the default node service account with a dedicated least-privileged one.
If you still need to restrict scopes explicitly
Create a new node pool with custom scopes and migrate workloads to it:
gcloud container node-pools create restricted-scope-pool --cluster=[CLUSTER_NAME] --location=[LOCATION] --service-account=[NODE_SA_EMAIL] --scopes=https://www.googleapis.com/auth/devstorage.read_only,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring
Validate the node-pool configuration:
gcloud container node-pools describe restricted-scope-pool --cluster=[CLUSTER_NAME] --location=[LOCATION] --format='yaml(config.serviceAccount,config.oauthScopes)'
Important note
You cannot modify access scopes on existing node pools in place. Create a replacement node pool and migrate workloads.
References
- https://cloud.google.com/kubernetes-engine/docs/how-to/access-scopes
- https://cloud.google.com/compute/docs/access/service-accounts
Service-wide remediation
Recommended when many resources are affected: prioritize least-privileged node service accounts and Workload Identity Federation. Use custom scopes only when you have a concrete reason to add that extra guardrail.
Review this control together with the node service account design rather than treating scopes as the primary control.
Operational rollout
- Verify the node service account roles first.
- If custom scopes are required by policy, create replacement node pools with the approved scopes.
- Migrate workloads and remove older pools after validation.
Query logic
These are the stored checks tied to this control.
Broad node OAuth access scopes are reviewed on Kubernetes Clusters
Connectors
Covered asset types
Expected check: eq []
{gkeClusters(where:{nodePools_SOME:{nodeConfig:{serviceAccount:"default" oauthScopes_INCLUDES:"https://www.googleapis.com/auth/cloud-platform"}}}){...AssetFragment}}
Google Cloud