More Info:
Kubernetes supports mounting secrets as data volumes or as environment variables. Minimize the use of environment variable secrets.Risk Level
HighAddress
SecurityCompliance 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
Remediation
Manual Steps
Manual Steps
-
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.
- Run on any machine with kubectl access:
-
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.
- For each item from step 1, describe it and review the env section:
-
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.
- Modify application code or configuration outside the cluster so it reads secrets from a file path (for example
-
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
enventries that usesecretKeyRef. - Add a
volumesentry at the pod spec level and avolumeMountsentry for the container. Example pattern:
- Remove
- Apply updated manifests if editing locally:
- Edit the manifest on any machine with kubectl access (either via file + apply, or
-
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
enventries withsecretKeyRefexist in that workload:
- Confirm the updated pods are running and healthy:
-
Verification (cluster-wide)
- Re-run the audit command from any machine with kubectl access:
- Repeat steps 2–5 until
NO_ENV_SECRET_REFERENCESis printed or only the explicitly accepted exceptions remain.
- Re-run the audit command from any machine with kubectl access:
Using kubectl
Using kubectl
On any machine with Edit After:Your application must be updated to read Repeat this export/edit/apply pattern for each affected controller kind:
kubectl access:- Identify workloads using
env/envFromsecret references
- For each affected Pod controller (Deployment/StatefulSet/DaemonSet/Job/CronJob), fetch the manifest, edit it locally, and re-apply.
deployment-with-env-secrets.yaml:- Remove
enventries that usesecretKeyRef, or entireenvFromentries that reference a Secret. - Add a
volumesourced from the Secret. - Mount that volume into the container at a path your application can read.
/etc/secrets/db/password instead of the environment variable.Apply the updated manifest:- Verification
secretKeyRef usages:Automation
Automation

