T09 · Insecure Skill Coding Practices
- Location
examples.md:639- Finding
Overly Broad OAuth Scope Assigned to GKE Nodes
- Content
View full analysis
Vulnerability Details
File Location:
examples.md:639-643,examples.md:709-713, andexamples.md:786-790
Vulnerability Type: Overly broad cloud API authorization scope
Risk Level: MediumThe Python, Java, and Go GKE creation examples assign the broad Google Cloud Platform OAuth scope to every cluster node.
python node_config=container_v1.NodeConfig( machine_type="e2-medium", disk_size_gb=100, oauth_scopes=[ "https://www.googleapis.com/auth/cloud-platform" ] ),java NodeConfig nodeConfig = NodeConfig.newBuilder() .setMachineType("e2-medium") .setDiskSizeGb(100) .addOauthScopes("https://www.googleapis.com/auth/cloud-platform") .build();go NodeConfig: &containerpb.NodeConfig{ MachineType: "e2-medium", DiskSizeGb: 100, OauthScopes: []string{ "https://www.googleapis.com/auth/cloud-platform", }, },Technical Analysis
The
cloud-platformOAuth scope permits tokens issued to the node service account to be presented to any Google Cloud API. OAuth scopes and IAM permissions are both evaluated, so this scope does not independently grant permissions that the service account lacks. Nevertheless, it removes OAuth scopes as a defense-in-depth restriction and makes the service account's IAM roles the only substantive authorization boundary.If a node uses a service account with excessive IAM permissions, a compromised workload capable of reaching the relevant metadata credentials could obtain a node service-account token and invoke every API operation allowed by those IAM roles. Repeating this configuration in several language examples increases the likelihood that users will deploy it without applying workload-specific identity controls.
Attack Path
A practical exploitation path requires both workload compromise and access to node credentials:
- A user deploys a cluster based on one of the affected examples.
- The cluster nodes use the broad `clou ...[truncated 1555 chars]
- Remediation
View remediation
Remediation Suggestions
-
Adopt Workload Identity Federation for GKE
- Map each Kubernetes service account to a dedicated, least-privilege Google Cloud identity.
- Grant cloud permissions to individual workloads rather than to the shared node identity.
- Ensure applications use their workload identity instead of node credentials.
-
Minimize the node service account
- Create a dedicated node service account instead of relying on a broadly privileged default service account.
- Grant only the roles required for node operation.
- Regularly review the service account through IAM policy analysis and remove unused permissions.
-
Restrict access to metadata credentials
- Use supported GKE metadata-protection controls.
- Verify that ordinary workloads cannot retrieve the underlying node service account's credentials.
- Apply appropriate network and workload isolation controls as additional defense in depth.
-
Avoid presenting
cloud-platformas a secure default- Update all Python, Java, Go, CLI, and Terraform examples consistently.
- If the broad scope is operationally necessary, explicitly state that security depends on least-privilege IAM and workload identity controls.
- Prefer current GKE configuration guidance that uses IAM and workload identities rather than shared node OAuth scopes.
-
Add deployment safeguards
- Run policy-as-code checks against sample Terraform and cluster definitions.
- Flag broadly privileged node service accounts and unrestricted OAuth scopes during CI.
- Test credential isolation from an unprivileged pod before approving production deployment.
-