Detections
Analytics

5.2.1 Use custom least privilege service accounts for GKE node pools

Information

Use a custom, least privilege IAM service account for GKE Standard node pools instead of the Compute Engine default service account. The node service account provides the default Google Cloud identity for nodes and should be limited to the permissions required for node level system tasks such as logging, monitoring, autoscaling metrics, and approved image pulls.

GKE nodes use an attached IAM service account to perform Google Cloud operations on behalf of node level system components. If a custom service account is not specified, GKE uses the Compute Engine default service account, which might also be used by other resources in the project and could have more permissions than GKE nodes require. Using a dedicated custom node service account reduces the blast radius if a node is compromised and makes node permissions easier to review and govern.

For GKE the node service account should have the roles/container.defaultNodeServiceAccount role, which is the least privilege role intended for GKE nodes. Additional permissions should be granted only when required, such as roles/artifactregistry.reader for pulling private images from Artifact Registry repositories. Workloads that need Google Cloud API access should use Workload Identity Federation for GKE rather than relying on the node service account.

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

Solution

Create a dedicated custom IAM service account for GKE Standard node pools that are using the Compute Engine default service account or a service account with excessive permissions. The custom node service account should be used for node level system tasks and should be granted only the permissions required for GKE node operation.

gcloud iam service-accounts create $NODE_SA_ACCOUNT \\
 --project=$PROJECT_ID \\
 --display-name="GKE Node Service Account"

Grant the custom node service account the current baseline GKE node role, roles/container.defaultNodeServiceAccount . This role is intended to provide the required permissions for GKE node operation, replacing the older approach of separately assigning logging and monitoring roles.

gcloud projects add-iam-policy-binding $PROJECT_ID \\
 --member=serviceAccount:$NODE_SA_ACCOUNT@$PROJECT_ID.iam.gserviceaccount.com \\
 --role=roles/container.defaultNodeServiceAccount

Grant roles only when required.

 - Example: If the node pool must pull private images from Artifact Registry, grant roles/artifactregistry.reader at the repository level when possible.

gcloud artifacts repositories add-iam-policy-binding $REPOSITORY \\
 --project=$PROJECT_ID \\
 --location=$LOCATION \\
 --member=serviceAccount:$NODE_SA_ACCOUNT@$PROJECT_ID.iam.gserviceaccount.com \\
 --role=roles/artifactregistry.reader

Create a new node pool that uses the custom node service account. The service account should be specified when the node pool is created, so node pools that use the Compute Engine default service account should be replaced with new node pools using the custom service account.

gcloud container node-pools create $NODE_POOL \\
 --cluster=$CLUSTER_NAME \\
 --location=$LOCATION \\
 --project=$PROJECT_ID \\
 --service-account=$NODE_SA_ACCOUNT@$PROJECT_ID.iam.gserviceaccount.com

After the new node pool is healthy, migrate workloads to the new node pool and validate node registration, logging, monitoring, autoscaling metrics, and private image pulls. Then drain and delete old node pools that use the Compute Engine default service account or an overly privileged service account.

Impact:

Replacing the Compute Engine default service account with a custom least privilege node service account may affect node registration, logging, monitoring, autoscaling metrics, image pulls, or workloads that incorrectly depend on node level permissions. Before enforcing this control, validate that the custom service account has the required GKE node permissions, repository read access for approved private images, and that application workloads use their own Kubernetes service accounts with Workload Identity Federation where Google Cloud API access is needed.

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: 5e53170a1387e5427da6f6522a01f298ae05da6e6458b4cec5777de6a9f793b5