Detections
Analytics

5.2.2 Use dedicated Kubernetes service accounts with Workload Identity Federation for GKE

Information

Use Workload Identity Federation for GKE to give GKE workloads distinct, least privilege identities when they need access to Google Cloud APIs. Workloads should use dedicated Kubernetes service accounts and IAM allow policies instead of relying on node service account permissions or long lived IAM service account keys.

Workloads that authenticate through node service account permissions or static IAM service account keys create unnecessary risk. Node service account permissions are shared across workloads running on the node, which weakens least privilege, while static keys introduce credential storage, rotation, and leakage concerns. Workload Identity Federation for GKE lets IAM trust Kubernetes identities and issue federated tokens without distributing Google Cloud credentials to workloads.

For GKE clusters, this federation model must be enabled at the cluster level and on the node pools that run the workloads. IAM access is then granted on the target Google Cloud resource to a principal identifier that represents the workload, namespace, or Kubernetes service account. When a target API does not support direct federated access, a Kubernetes service account can be configured to impersonate a dedicated IAM service account.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

This remediation is important when GKE Standard workloads rely on node service account permissions, mounted IAM service account keys, or shared Kubernetes service accounts to access Google Cloud APIs. Enabling Workload Identity Federation for GKE and using dedicated Kubernetes service accounts allows each workload to receive only the Google Cloud permissions it needs, reducing reliance on broad node level permissions and improving workload level identity separation.

Enable Workload Identity Federation for GKE on the GKE Standard cluster if the workload pool is not configured.

gcloud container clusters update $CLUSTER_NAME \\
 --location=$LOCATION \\
 --project=$PROJECT_ID \\
 --workload-pool=$PROJECT_ID.svc.id.goog

Enable the GKE metadata server on existing node pools that run workloads requiring Google Cloud API access. Existing node pools are not automatically updated when the cluster setting is enabled, so they must be updated or replaced.

gcloud container node-pools update $NODE_POOL \\
 --cluster=$CLUSTER_NAME \\
 --location=$LOCATION \\
 --project=$PROJECT_ID \\
 --workload-metadata=GKE_METADATA

Create a dedicated Kubernetes service account for each workload or application that requires Google Cloud API access instead of using the namespace default service account.

 -

Grant the required IAM role on the target Google Cloud resource to the specific Kubernetes principal identifier for the namespace and Kubernetes service account. Grant only the permissions required by the workload.

 -

Update the workload manifest so the Pod runs as the dedicated Kubernetes service account. For GKE Standard clusters, ensure the workload is scheduled onto a node pool that uses the GKE metadata server.

Redeploy the workload and test Google Cloud API access to confirm the federated identity configuration works as expected. Update any workloads that previously depended on node service account permissions or mounted IAM service account keys to use the dedicated Kubernetes service account and IAM allow policy model.

Impact:

Enabling Workload Identity Federation for GKE can require updates to clusters, node pools, Kubernetes service accounts, workload manifests, and IAM allow policies. Existing workloads that depended on node service account permissions or mounted key files might lose access until permissions are explicitly granted through the federated identity model. For Standard clusters, workloads must run on node pools using the GKE metadata server, and restrictive egress policies should allow required access to the metadata server.

See Also

https://workbench.cisecurity.org/benchmarks/24956

Item Details

Category: IDENTIFICATION AND AUTHENTICATION

References: 800-53|IA-5, CSCv7|4.3

Plugin: GCP

Control ID: 7037fc6c8877a4852b67506478a080d1fa9711176de2d9de90e924659d99b0c0