Skip to main content

More Info:

Verifies secret-like env vars are not set as literal values. Literal values land in the pod manifest, logs and kubectl describe.

Risk Level

Medium

Address

Security

Compliance Standards

  • Cloudanix Best Practice

Triage and Remediation

Remediation

Manual Steps

  1. On any machine with kubectl access, list offending Pods so you know what to fix (capture output for reference):
  2. For one offending Pod, identify its controller (Deployment/StatefulSet/Job/etc.) and confirm you will edit the controller, not the live Pod:
    If there is no ownerReferences entry, the Pod is standalone and must be edited or recreated directly.
  3. Create a Kubernetes Secret in the same namespace to hold the sensitive value (replace names and values appropriately):
  4. Edit the owning controller manifest (or the standalone Pod) to replace the literal value: with valueFrom.secretKeyRef for each sensitive env var, using kubectl edit on any machine with kubectl access:
    In the editor, change:
    to:
    Save and exit; Kubernetes will roll out updated Pods automatically.
  5. For standalone Pods (no controller), export the manifest, modify it, delete the old Pod, and recreate it:
  6. Verify that no sensitive values are still passed as literal env vars by rerunning the audit command from any machine with kubectl access; compliance is shown when it returns only is_compliant=true:
On any machine with kubectl access:
  1. Identify offending Pods and their env vars (example using the audit logic):
  1. For each Pod owned by a controller (Deployment/StatefulSet/Job/CronJob, etc.), edit the controller, not the Pod. Example: convert a literal DB_PASSWORD env var in a Deployment to use a Secret.
2.1. Create a Secret containing the sensitive value (replace placeholders with your real values):
2.2. Edit the owning Deployment to use valueFrom.secretKeyRef:
In the container spec, replace:
with:
Save and exit; Kubernetes will roll out new Pods for that Deployment using the Secret.
  1. If you prefer fully declarative changes, fetch, edit locally, and apply:
Edit deployment.yaml to remove literal secret values and reference Secrets via valueFrom.secretKeyRef as above, then apply:
  1. For workloads using volume-mounted Secrets instead of env vars, create the Secret as in 2.1, then add:
and update your app to read from the mounted file.
  1. Verification (same audit command; a compliant cluster prints only is_compliant=true):