Back to controls

Review broad node OAuth access scopes on Kubernetes Clusters

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.

Category

Controls

Low

Applies to

Google Cloud

Coverage

1 queries

Asset types

1 covered

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

  1. https://cloud.google.com/kubernetes-engine/docs/how-to/access-scopes
  2. 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

  1. Verify the node service account roles first.
  2. If custom scopes are required by policy, create replacement node pools with the approved scopes.
  3. 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

Google Cloud

Covered asset types

Cluster

Expected check: eq []

{gkeClusters(where:{nodePools_SOME:{nodeConfig:{serviceAccount:"default" oauthScopes_INCLUDES:"https://www.googleapis.com/auth/cloud-platform"}}}){...AssetFragment}}
Cyscale Logo
Cyscale is an agentless cloud-native application protection platform (CNAPP) that automates the contextual analysis of cloud misconfigurations, vulnerabilities, access, and data, to provide an accurate and actionable assessment of risk.

Stay connected

Receive new blog posts and product updates from Cyscale

By clicking Subscribe, I agree to Cyscale’s Privacy Policy


© 2026 Cyscale Limited

LinkedIn icon
Twitter icon
Facebook icon
crunch base icon
angel icon