4.4.2 Use Secret Manager for external workload secret storage

Information

Use Secret Manager as the preferred external storage and management service for workload secrets used by GKE Standard clusters. Workloads should access secrets through Secret Manager API calls using Workload Identity Federation for GKE, or through mounted volumes using the Secret Manager add-on when file based access is required.

Kubernetes Secrets are supported, but they require careful control through Kubernetes RBAC, namespace boundaries, encryption, and workload configuration. Storing sensitive values in Secret Manager centralizes secret lifecycle management outside the cluster and supports IAM based access control, auditability, rotation, and version management. Workload Identity Federation for GKE lets workloads access Secret Manager without static service account keys and allows access to be granted to specific Kubernetes ServiceAccounts.

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

Solution

Move externally managed workload secrets to Secret Manager and update GKE workloads to access them through Workload Identity Federation for GKE. Prefer direct Secret Manager API access through Google Cloud client libraries where the application supports it. For applications that require file based secret access, enable the Secret Manager add-on and mount secrets into Pods using SecretProviderClass and CSI volumes.

-

Enable Workload Identity Federation for GKE on the Standard cluster and required node pools.

-

Use dedicated Kubernetes ServiceAccounts for workloads that need Secret Manager access.

-

Grant least privilege Secret Manager IAM permissions only to the required workload identities.

-

Enable the Secret Manager add-on when workloads need secrets mounted as files.

-

Migrate sensitive values out of Kubernetes Secrets where practical, then remove unused in-cluster Secret objects.

Secret Manager provides centralized secret management features such as fine grained access control, managed rotation, lifecycle management, and audit logs.

Impact:

Applications might require code, deployment, or configuration changes to retrieve secrets from Secret Manager or mounted files instead of relying directly on Kubernetes Secrets. Admins must configure Workload Identity Federation for GKE, bind the correct IAM permissions to the workload identity, validate secret access during startup and rotation, and update operational procedures for versioning, access review, and troubleshooting.

See Also

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

Item Details

Category: SYSTEM AND COMMUNICATIONS PROTECTION

References: 800-53|SC-7(10), CSCv7|13

Plugin: GCP

Control ID: d84222245aa9daa216ee96b2285a0cebdae3421a1f20d58e42f2d884b8e6cca1