Description
Passing Secret values through environment variables can expose them in application logs, debugging output or process dumps. This is a supported delivery mechanism and does not itself prove a leak; review actual output and access permissions. Environment variables in a running container do not refresh automatically when the source Secret changes.
Potential impact
- Leaked secrets can be used to access other systems.
- Applications still using old values can fail authentication after secret rotation.
Remediation
- If the application can read files, consider delivering only the required Secret keys through a read-only volume. Check file permissions and how the application detects and reloads changes.
- When using environment variables, restrict value output and debugging, and plan restarts during secret rotation. Minimize Secret read and Pod execution/debugging permissions, and revoke credentials that are no longer used.
Examples
mysecret must exist in the same namespace. These examples do not make the Redis image automatically use the variable or file for authentication; application handling must be implemented separately. The different Pod names create separate resources.
Before
apiVersion: v1
kind: Pod
metadata:
name: secret-env-pod
spec:
containers:
- name: mycontainer
image: redis
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
The username value from mysecret is passed through the SECRET_USERNAME environment variable.
After
apiVersion: v1
kind: Pod
metadata:
name: secret-file-pod
spec:
containers:
- name: mycontainer
image: redis
volumeMounts:
- name: app-secret
mountPath: /var/run/secrets/app
readOnly: true
volumes:
- name: app-secret
secret:
secretName: mysecret
Secret keys are mounted as files under /var/run/secrets/app. This example mounts all keys; select only those needed and account for the fact that authorized processes or users can also read file-based secrets.