Detections
Analytics

5.2.2 Prefer using dedicated GCP Service Accounts and Workload Identity

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

Kubernetes workloads should not use cluster node service accounts to authenticate to Google Cloud APIs. Each Kubernetes Workload that needs to authenticate to other Google services using Cloud IAM should be provisioned a dedicated Service account. Enabling Workload Identity manages the distribution and rotation of Service account keys for the workloads to use.

Rationale:

Manual approaches for authenticating Kubernetes workloads running on GKE against Google Cloud APIs are: storing service account keys as a Kubernetes secret (which introduces manual key rotation and potential for key compromise); or use of the underlying nodes' IAM Service account, which violates the principle of least privilege on a multitenanted node, when one pod needs to have access to a service, but every other pod on the node that uses the Service account does not.

Once a relationship between a Kubernetes Service account and a GCP Service account has been configured, any workload running as the Kubernetes Service account automatically authenticates as the mapped GCP Service account when accessing Google Cloud APIs on a cluster with Workload Identity enabled.

Impact:

During the Workload Identity beta, a GCP project can have a maximum of 20 clusters with Workload Identity enabled.

Workload Identity replaces the need to use Metadata Concealment and as such, the two approaches are incompatible. The sensitive metadata protected by Metadata Concealment is also protected by Workload Identity.

When Workload Identity is enabled, you can no longer use the Compute Engine default Service account. Correspondingly, Workload Identity can't be used with Pods running in the host network. You may also need to modify workloads in order for them to use Workoad Identity as described within https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity

GKE infrastructure pods such as Stackdriver will continue to use the Node's Service account.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.

Solution

Using Google Cloud Console:

Go to Kubernetes Engine by visiting https://console.cloud.google.com/kubernetes/list

From the list of clusters, select your cluster for which Workload Identity is disabled.

Click on EDIT

Set Workload Identity to 'Enabled' and set the Workload Identity Namespace to the namespace of the Cloud project containing the cluster, e.g: [PROJECT_ID].svc.id.goog

Click SAVE and wait for the cluster to update

Once the cluster has updated, select each Node pool within the cluster Details page

For each Node pool, select EDIT within the Node pool Details page

Within the Edit node pool pane, check the 'Enable GKE Metadata Server' checkbox and click SAVE.

Using Command Line:

gcloud beta container clusters update [CLUSTER_NAME] --zone [CLUSTER_ZONE] \
 --identity-namespace=[PROJECT_ID].svc.id.goog

Note that existing Node pools are unaffected. New Node pools default to --workload-metadata-from-node=GKE_METADATA_SERVER.
Then, modify existing Node pools to enable GKE_METADATA_SERVER:

gcloud beta container node-pools update [NODEPOOL_NAME] \
 --cluster=[CLUSTER_NAME] --zone [CLUSTER_ZONE] \
 --workload-metadata-from-node=GKE_METADATA_SERVER

You may also need to modify workloads in order for them to use Workload Identity as described within https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity. Also consider the effects on the availability of your hosted workloads as Node pools are updated, it may be more appropriate to create new Node Pools.

Default Value:

By default, Workload Identity is disabled.

See Also

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

Item Details

References: CSCv7|4.3

Plugin: GCP

Control ID: 47bd741fd7d96ef3d5af333230cce545677678a57b0ed2e21d74f2309772553b