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. List offending Pods and identify the owning workload (run on any machine with kubectl access):
    From each line, note ns=..., owner=... (e.g., Deployment/default/my-app/...), container=..., and env=....
  2. For each offending env var, create or update a Secret holding the sensitive value (run on any machine with kubectl access, per namespace). Replace placeholders with the real values:
    Use one key per env var (e.g., DB_PASSWORD, API_TOKEN).
  3. Patch the owning workload manifest to use valueFrom.secretKeyRef instead of a literal value: (run on any machine with kubectl access). First, export the current manifest:
    Then edit /tmp/my-app-deploy.yaml:
    • Find the container with the offending env, e.g.:
    • Replace with:
    • Ensure you do this for every env var flagged by the audit.
  4. Apply the updated workload manifest so new Pods use the Secret (run on any machine with kubectl access):
    For controllers that don’t roll Pods automatically (e.g., some StatefulSets/Jobs), trigger a restart as appropriate, understanding this will restart the affected Pods.
  5. Confirm new Pods no longer contain literal sensitive values in their env definition (run on any machine with kubectl access):
    You should see only a valueFrom: secretKeyRef: block and no value: line for the sensitive variable names.
  6. Re-run the benchmark audit to verify compliance (run on any machine with kubectl access):
    The cluster is compliant when the output shows is_compliant=true and no is_compliant=false rows.
On any machine with kubectl access to the cluster:
  1. Identify the offending Pod and env var from the finding output, for example:
    • Namespace: app-namespace
    • Pod name: web-7c9c6c7d4b-abcde
    • Container: web
    • Env var: DB_PASSWORD
  2. Extract the current Pod spec (for reference only; do not apply this Pod directly because it is usually managed by a controller such as a Deployment):
  1. Determine the owning controller (e.g., Deployment) from the owner= field in the finding or via:
Assume the result is Deployment web.
  1. Create a Secret that will hold the sensitive value (if one does not already exist). Replace the literal with the real value:
  1. Patch the owning Deployment to reference the Secret via valueFrom.secretKeyRef instead of a literal value:. First, fetch the Deployment manifest:
  1. Edit /tmp/web-deploy.yaml:
    • In the relevant container under spec.template.spec.containers[], find the existing env entry:
  • Replace it with:
  1. Apply the updated Deployment manifest:
This will recreate Pods managed by the Deployment with the Secret-based env var.
  1. Verification: rerun the audit (or a scoped variant) and confirm no is_compliant=false rows remain for this Pod/container/env: