Skip to main content

​
Impact & Risk Analysis

  • Severity: Medium (Level 2 - Defense in Depth)
  • CIS Benchmark: CIS 5.4.1
  • Impact: Data Leakage via Logs. It is very common for application frameworks to log their entire environment context when they crash or encounter an unhandled exception. If secrets are stored as environment variables, they will be printed in cleartext to the application logs (and subsequently shipped to your logging aggregation system like Splunk or Elasticsearch), making them visible to anyone with log read access.

​
Common Misconfiguration

Using env with valueFrom and secretKeyRef. This is the easiest way to inject configuration, so developers default to it, ignoring the risk of crash dump leakage.

​
Vulnerable Example

# Vulnerable Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: insecure-app
spec:
  template:
    spec:
      containers:
      - name: app
        image: my-app
        env:
        # VULNERABLE: Secret injected as Environment Variable
        # If the app crashes and dumps 'env', this password is leaked.
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: password

​
Secure Example

# Secure Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
spec:
  template:
    spec:
      containers:
      - name: app
        image: my-app
        # SECURE: Mount the secret as a file
        volumeMounts:
        - name: secret-volume
          mountPath: "/etc/secrets"
          readOnly: true
      volumes:
      - name: secret-volume
        secret:
          secretName: db-secret
Note: Application code must be updated to read the file /etc/secrets/password instead of reading os.environ['DB_PASSWORD'].

​
Audit Procedure

Run the following command to find any workloads that inject secrets into environment variables: 
kubectl get all -o jsonpath='{range .items[?(@..secretKeyRef)]} {.kind} {.metadata.name} {"\n"}{end}' -A
  • Result: A list of Deployments, StatefulSets, or DaemonSets.
  • Analyze: Any item in this list is using secretKeyRef in an env block and is potentially vulnerable to log leakage.

​
Remediation

  1. Refactor Code: Modify your application to read secrets from the filesystem (e.g., /etc/secrets/) rather than environment variables.
  2. Update Manifests: Change your Deployment YAML to use volumes and volumeMounts instead of env.
Bonus Benefit: Secrets mounted as files update automatically when the Secret object changes in Kubernetes (no Pod restart required). Environment variables require a Pod restart to pick up changes.