> ## Documentation Index
> Fetch the complete documentation index at: https://guide.codepure.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Prefer Using Secrets as Files Over Environment Variables (CIS 5.4.1)

> Prevent accidental secret leakage in logs by mounting secrets as volumes

## 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

```yaml theme={null}
# 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

```yaml theme={null}
# 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:

```bash theme={null}
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.