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 and pick one to fix:
  2. For each offending Pod, identify whether it is managed by a higher‑level controller (Deployment, StatefulSet, etc.) and capture that object for editing:
  3. Create or update a Secret object that will hold the sensitive value, in the same namespace:
  4. Edit the controller manifest to replace literal value: with valueFrom.secretKeyRef for each sensitive env var (do not edit Pods directly, as they will be recreated):
  5. Wait for the updated Pods to roll out and ensure the old ones are gone:
  6. Verify the cluster is now compliant by rerunning the audit command from any machine with kubectl access; it should print is_compliant=true and no individual violations:
On any machine with kubectl access:
  1. Identify the offending Pod and env var
Pick one violating Pod line and note: ns, name, container, and the env name.
  1. Export the owning workload manifest
If the Pod is controlled by a Deployment (adjust kind if it’s a StatefulSet, DaemonSet, Job, etc.):
  1. Create a Secret to hold the sensitive value
Replace MY_SECRET_ENV, my-secret-name, and actual-secret-value appropriately:
  1. Edit the manifest to use valueFrom.secretKeyRef
Open /tmp/deployment-secured.yaml and in the relevant container’s env section, replace:
with:
Ensure indentation is valid and that you modify all containers / initContainers that used the literal value.
  1. Apply the updated manifest
GKE will roll out new Pods with the Secret-based env var.
  1. Verification
Re-run the benchmark audit command and confirm either is_compliant=true is printed or that the specific Pod/env no longer appears: