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)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS GKE
  • 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. Identify workloads using secrets as environment variables
    • Run on any machine with kubectl access:
    • Save the output and decide which Deployments/DaemonSets/StatefulSets/Pods/Jobs/CronJobs you will change.
  2. Inspect how the secret is used in each workload
    • For each item from step 1, describe it and review the env section:
    • Confirm the application reads the secret from environment variables and determine if it can instead read from a file path.
  3. Update application code/configuration to read secrets from files
    • Modify application code or configuration outside the cluster so it reads secrets from a file path (for example /var/run/secrets/<app>/<key>) instead of an environment variable.
    • Build and push the updated image or adjust configuration so that the application expects the secret at the chosen file path.
  4. Modify the workload manifest to mount the secret as a volume
    • Edit the manifest on any machine with kubectl access (either via file + apply, or kubectl edit):
      • Remove env entries that use secretKeyRef.
      • Add a volumes entry at the pod spec level and a volumeMounts entry for the container. Example pattern:
    • Apply updated manifests if editing locally:
  5. Validate application behavior and remove remaining env-secret usage
    • Confirm the updated pods are running and healthy:
    • If the application works with file-based secrets, ensure no remaining env entries with secretKeyRef exist in that workload:
  6. Verification (cluster-wide)
    • Re-run the audit command from any machine with kubectl access:
    • Repeat steps 2–5 until NO_ENV_SECRET_REFERENCES is printed or only the explicitly accepted exceptions remain.
On any machine with kubectl access:
  1. Identify workloads using env/envFrom secret references
  1. For each affected Pod controller (Deployment/StatefulSet/DaemonSet/Job/CronJob), fetch the manifest, edit it locally, and re-apply.
Example for a Deployment:
Edit deployment-with-env-secrets.yaml:
  • Remove env entries that use secretKeyRef, or entire envFrom entries that reference a Secret.
  • Add a volume sourced from the Secret.
  • Mount that volume into the container at a path your application can read.
Example transformation:Before:
After:
Your application must be updated to read /etc/secrets/db/password instead of the environment variable.Apply the updated manifest:
Repeat this export/edit/apply pattern for each affected controller kind:
  1. Verification
After updating all workloads and redeploying the application code to read mounted files, confirm there are no remaining secretKeyRef usages:

Additional Reading: