A Secret reaches a container the same three ways a ConfigMap does, with secret in the field names.
yaml
spec:
containers:
- name: api
image: stackmonsters/monster-market-api
env:
- name: MONSTER_DB_URL
valueFrom:
secretKeyRef:
name: db-creds
key: url
envFrom:
- secretRef:
name: db-creds
volumeMounts:
- name: creds
mountPath: /etc/creds
readOnly: true
volumes:
- name: creds
secret:
secretName: db-creds| ConfigMap | Secret |
|---|---|
configMapKeyRef | secretKeyRef |
envFrom.configMapRef | envFrom.secretRef |
volumes[].configMap.name | volumes[].secret.secretName |
Inside the container the value is plain text, decoded for you: printenv MONSTER_DB_URL prints the URL, cat /etc/creds/url prints it too.
Rotation
Replacing a Secret does not touch running containers. Their environment was fixed when they started.
1. Replace the Secretkubectl delete secret db-creds · kubectl create secret generic db-creds --from-literal=url=...
2. Recreate the Pods that read itkubectl rollout restart deploy/market-api
rollout restart changes nothing in the template but a timestamp annotation. That is still a change, so a rollout runs and every new Pod reads the new value.
When the key is wrong
The Deployment asks for key MONSTER_DB_URL; the Secret has DB_URL. The Pod does not start:
text
learner@shallows:~$ kubectl get pods
NAME READY STATUS RESTARTS AGE
market-api-6f9b8c7d5f-x2kqp 0/1 CreateContainerConfigError 0 30s
learner@shallows:~$ kubectl describe pod market-api-6f9b8c7d5f-x2kqp | tail -1
Warning Failed kubelet Error: couldn't find key MONSTER_DB_URL in Secret caverns/db-credsFix the Secret or the reference; the Pod starts by itself.