Skip to main content

More Info:

Kubernetes supports mounting secrets as data volumes or as environment variables. Minimize the use of environment variable secrets.

Risk Level

High

Address

Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • AWS Startup Security Baseline
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS EKS
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Manual Steps

  1. List all workloads using secrets as environment variables
    • Run on: any machine with kubectl access.
  2. Inspect a specific workload’s env-based secret usage
    • Pick one namespace/kind/name from step 1 and inspect its manifest:
    • In the downloaded YAML, locate env: entries that use valueFrom.secretKeyRef.
  3. Refactor the manifest to mount secrets as files instead of env vars
    • Edit the saved manifest file on your local machine:
    • Under spec.template.spec, add or update a volumes entry referencing the secret:
    • For each container that currently uses env.valueFrom.secretKeyRef, remove those env entries and mount the secret as a volume:
    • Ensure the application code/config is updated to read the secret from the mounted file path (for example, /var/run/secrets/app/KEY_NAME). This requires application changes outside of Kubernetes and must be coordinated with the application owner.
  4. Apply the updated manifest to the cluster
    • Run on: any machine with kubectl access.
    • Repeat steps 2–4 for each resource reported in step 1 (Deployment, StatefulSet, DaemonSet, Job, CronJob, etc.), adapting kind and filenames as needed.
  5. Optionally remove any remaining env-based secret refs programmatically (review required)
    • To review all manifests currently using secretKeyRef before final cleanup:
    • Manually confirm each usage is safe to remove and that the application reads from files; then adjust the corresponding manifests as in steps 2–4. Do not delete env entries without confirming application behavior.
  6. Verify no secrets are used as environment variables
    • Run on: any machine with kubectl access.
On any machine with kubectl access:
  1. Identify workloads using secretKeyRef (same as audit)
  1. For each listed object, switch from env-var secrets to volume-mounted secrets.
Example: convert a Deployment using env.valueFrom.secretKeyRef to use a Secret volume.Before (env-var based):
Edit /tmp/my-app-deployment.yaml and replace:
with volume-based access:
Make sure volumes: is under spec.template.spec and volumeMounts: is under the container spec. Adjust mountPath, name, and secretName as needed. Your application code must read from the file path (e.g., /var/run/secrets/db/password) instead of the environment variable.
  1. Apply the updated manifest (this will roll the workload)
Repeat step 2–3 for each Deployment/StatefulSet/DaemonSet/Pod reported in step 1.
  1. Verification (no remaining secretKeyRef in running workloads)

Additional Reading: