Skip to main content

More Info:

Secrets exposed as environment variables are more likely to be leaked through logs, child processes, or crash dumps. Prefer mounting secrets as files for improved confidentiality.

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS EKS

Triage and Remediation

Remediation

Manual Steps

  1. List all pods using secrets as environment variables (run on any machine with kubectl access):
  2. For each affected workload (Deployment/StatefulSet/DaemonSet/Job/CronJob), export its manifest (run on any machine with kubectl access, example for a Deployment):
  3. In the saved manifest file, manually:
    • Under spec.template.spec, add or extend a volumes entry to mount the secret:
    • Under the container spec, add or extend volumeMounts:
    • Remove any env or envFrom entries that use secretKeyRef for that secret, and adjust your application code/config to read from the mounted file path instead.
  4. Apply the updated manifest (this will roll pods; run on any machine with kubectl access):
  5. Repeat steps 2–4 for each listed resource kind (e.g., statefulset, daemonset, job, cronjob) that uses secretKeyRef in env or envFrom.
  6. Verify no workloads are using secrets as environment variables (run on any machine with kubectl access):
On any machine with kubectl access:
  1. Identify pods using secrets as environment variables
Pick one workload (example below uses a Deployment in namespace default named my-app).
  1. Export its manifest for editing
  1. Edit the manifest to replace env-based secrets with mounted secret files
In my-app-deploy.yaml, locate the container using secretKeyRef, for example:
Change it to mount the secret as a volume and have the app read from the file path instead of the env var. Remove the env entry and add volumeMounts and a volumes section like:
After this change, application code must read /etc/secrets/db/password instead of DB_PASSWORD. This code change is outside kubectl’s scope and must be done in the application.
  1. Apply the updated manifest
Repeat steps 2–4 for each workload found in step 1.
  1. Verification (cluster-wide)