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
MediumAddress
SecurityCompliance Standards
- Cloudanix Best Practice
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
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=..., andenv=.... -
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). -
Patch the owning workload manifest to use
valueFrom.secretKeyRefinstead of a literalvalue:(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.
- Find the container with the offending env, e.g.:
-
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.
-
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 novalue:line for the sensitive variable names. -
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=trueand nois_compliant=falserows.
Using kubectl
Using kubectl
On any machine with kubectl access to the cluster:Assume the result is This will recreate Pods managed by the Deployment with the Secret-based env var.
-
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
- Namespace:
- 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):
- Determine the owning controller (e.g., Deployment) from the
owner=field in the finding or via:
Deployment web.- Create a Secret that will hold the sensitive value (if one does not already exist). Replace the literal with the real value:
- Patch the owning Deployment to reference the Secret via
valueFrom.secretKeyRefinstead of a literalvalue:. First, fetch the Deployment manifest:
- Edit
/tmp/web-deploy.yaml:- In the relevant container under
spec.template.spec.containers[], find the existing env entry:
- In the relevant container under
- Replace it with:
- Apply the updated Deployment manifest:
- Verification: rerun the audit (or a scoped variant) and confirm no
is_compliant=falserows remain for this Pod/container/env:
Automation
Automation

