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. Identify offending Pods and env vars (any machine with kubectl access)
  2. For one violating Pod, capture its manifest (any machine with kubectl access)
    Replace NAMESPACE and POD_NAME with values from step 1.
  3. Create a Secret containing the sensitive value (any machine with kubectl access)
    Choose a Secret name and key, then run:
    Repeat with additional --from-literal=KEY='VALUE' flags for each sensitive env var.
  4. Edit the Pod’s manifest to use valueFrom.secretKeyRef (any machine with kubectl access)
    Open the file from step 2 and, under the relevant container’s env: section, replace:
    with:
    Do this for each sensitive variable, ensuring key: matches what you stored in the Secret.
  5. Recreate the Pod so it uses the Secret-based env vars (any machine with kubectl access)
    For Pods managed by a higher-level controller (e.g., Deployment, StatefulSet), edit the controller instead of the live Pod. Example for a Deployment:
    Apply the same env: changes to the Deployment spec, then let Kubernetes roll out new Pods.
    If it is a standalone Pod (no controller), delete and recreate it from the edited manifest:
  6. Verify the cluster is compliant (any machine with kubectl access)
    Confirm the output is is_compliant=true or that no lines for the fixed Pods remain.
On any machine with kubectl access:
  1. Identify the violating Pod and env var (from the audit output):
  • Example:
    • Namespace: default
    • Pod name: my-app-abc123
    • Container: app
    • Offending env: DB_PASSWORD
  1. Create a Secret that will hold the sensitive value (one-time, per app/namespace):
  1. Export the current Pod manifest, edit it to use valueFrom.secretKeyRef, and apply it via its controller (Deployment, StatefulSet, etc.).
    If the Pod is standalone (no controller), you must recreate it from a manifest.
a) Get the owning controller kind/name from the audit output (owner= field) or via:
Assume it is a Deployment named my-app.b) Export the Deployment manifest:
c) Edit my-app-deploy.yaml:Locate the container and replace the literal value: with valueFrom.secretKeyRef:
Remove any previous value: ... line for DB_PASSWORD.d) Apply the updated manifest:
This will roll out new Pods using the Secret-based env var.
  1. Verification:
Run the audit command again and ensure there is no line for this Pod/env and that you see is_compliant=true when all violations are fixed: