Detections
Analytics

4.4.1 Prefer using secrets as files over secrets as environment variables

Information

GKE workloads should avoid consuming secrets as environment variables. Prefer accessing secrets directly from Secret Manager by using Workload Identity Federation for GKE and client libraries, or mount secrets as files by using the Secret Manager add-on when file based access is required.

Secrets exposed as environment variables can be unintentionally disclosed through application logs, debug output, crash reports, process inspection, or overly broad troubleshooting access. Direct Secret Manager API access reduces secret exposure inside the cluster and avoids long lived service account keys when paired with Workload Identity Federation for GKE. Mounted files are still preferable to environment variables when the application cannot call the Secret Manager API directly, but file permissions, pod access, and IAM bindings must be tightly controlled.

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

Solution

Update workloads to avoid passing secrets through environment variables. Prefer direct Secret Manager API access through Workload Identity Federation for GKE and Google Cloud client libraries. This keeps sensitive data outside cluster storage, avoids long lived service account keys, and uses IAM rather than in cluster RBAC for Secret Manager access.

 -

Modify application code to read secrets from Secret Manager API where possible.

 -

Use a dedicated Kubernetes ServiceAccount for each workload identity that needs Secret Manager access.

 -

Grant only the required Secret Manager IAM permissions to that workload identity.

 -

When code cannot call the API directly, use the Secret Manager add-on to mount secrets as files in the Pod file system.

 -

Remove secretKeyRef and secretRef environment variable usage from workload manifests after the new access pattern is validated.

For mounted file access, enable the Secret Manager add-on and define a SecretProviderClass that maps specific Secret Manager secrets to Pod volumes. The add-on lets applications access Secret Manager secrets as mounted volumes and supports centralized Secret Manager capabilities such as fine grained access control, rotation, lifecycle management, and audit logs.

Impact:

Applications that currently read secrets from environment variables might need code, configuration, or deployment changes to read secrets from the Secret Manager API or from mounted files. Workloads must use an appropriate Kubernetes ServiceAccount, IAM permissions must allow access to the required Secret Manager secrets, and teams should validate startup behavior, secret rotation handling, and file path configuration before deployment.

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: c7ce8aa4071d7f9e25f3247e5e3511fff0bd441df4f0b66c2507c5485dd349a7