A pod references a specific key within a Secret that doesn't exist. Secret keys are case-sensitive and must match exactly. Fix by verifying key names in the Secret match pod references, or marking the reference as optional to allow startup.
When a pod references a Secret, it can either mount the entire Secret as a volume (all keys become files) or reference specific keys for environment variables or volume projections. If the pod tries to access a key that doesn't exist in the Secret's data, Kubernetes cannot satisfy the reference. This is different from a missing Secret itself—the Secret exists, but it doesn't contain the specific key-value pair the pod is requesting. Key names are case-sensitive and must match exactly.
Examine the Secret's actual data:
kubectl get secret <secret-name> -n <namespace> -o yamlThe output shows the data section with all key-value pairs. Keys are case-sensitive. Example:
kind: Secret
metadata:
name: db-secrets
data:
username: YWRtaW4= # base64 for "admin"
password: c2VjcmV0MTIz # base64 for "secret123"This Secret has exactly two keys: username and password. Any other key references will fail.
Examine how the pod references Secret keys:
kubectl get pod <pod-name> -n <namespace> -o yamlLook for:
Environment variable references:
env:
- name: DB_USER
valueFrom:
secretKeyRef:
name: db-secrets
key: username # This key must exist in the SecretVolume projections:
volumes:
- name: secrets
secret:
secretName: db-secrets
items:
- key: username
path: user.txt
- key: password
path: pass.txtCompare the key values with those shown in step 1. Any mismatch will cause the error.
If the key name is wrong in the pod spec, update it to match the Secret:
Option A: Fix the pod manifest
Update the key name to match the Secret:
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: db-secrets
key: password # Changed from "passwd" to "password"Reapply:
kubectl apply -f pod.yamlOption B: Fix the Secret (if the Secret is wrong)
If the Secret is missing the expected key, add it:
kubectl patch secret db-secrets -p '{"data":{"password":"'$(echo -n "mypassword" | base64)'"}}' -n <namespace>Or update via YAML:
kubectl edit secret db-secrets -n <namespace>Add the missing key in the data section (values must be base64-encoded).
Key names are case-sensitive. These are three different keys:
- password
- Password
- PASSWORD
If pod references password but Secret has PASSWORD, it will fail. Double-check capitalization:
kubectl get secret db-secrets -n <namespace> -o jsonpath='{.data}\n'This shows all keys without base64 encoding, making it easier to verify exact names.
If the Secret is missing multiple keys, recreate it:
kubectl delete secret db-secrets -n <namespace>Then create a new one with all required keys:
kubectl create secret generic db-secrets \
--from-literal=username=admin \
--from-literal=password=secret123 \
--from-literal=host=db.example.com \
-n <namespace>Or use YAML:
apiVersion: v1
kind: Secret
metadata:
name: db-secrets
namespace: production
type: Opaque
stringData:
username: admin
password: secret123
host: db.example.comApply: kubectl apply -f secret.yaml
If the key is optional (not essential for application startup), mark it as optional:
For environment variables:
env:
- name: OPTIONAL_KEY
valueFrom:
secretKeyRef:
name: db-secrets
key: optional-setting
optional: true # Pod starts even if key is missingFor volume projections:
volumes:
- name: secrets
secret:
secretName: db-secrets
items:
- key: optional-key
path: optional.txt
mode: 0644When optional: true, the pod starts without that environment variable or volume file. The application must handle missing values gracefully.
After fixing key mismatches, verify the pod starts:
kubectl get pod <pod-name> -n <namespace>
kubectl describe pod <pod-name> -n <namespace>Pod status should be Running. Check logs:
kubectl logs <pod-name> -n <namespace>Verify environment variables were injected correctly:
kubectl exec <pod-name> -n <namespace> -- env | grep -i secretOr check volume mount:
kubectl exec <pod-name> -n <namespace> -- ls -la /etc/secrets/Key names are case-sensitive and whitespace matters—avoid spaces and special characters in key names. When creating Secrets from files with kubectl create --from-file, the filename becomes the key and the file contents become the value; this is useful for certificates and config files. Secret values are base64-encoded (not encrypted) in etcd by default; enable encryption at rest to protect sensitive data. Use stringData field in YAML for plain text values; Kubernetes automatically base64-encodes them. When referencing multiple keys from the same Secret using volume projections, use the items[] field to list only needed keys; unlisted keys won't be mounted. For validation: use kubectl apply --dry-run=client to catch key mismatches before deploying. Secret updates propagate to running pods after ~1 minute (kubelet sync period); for immediate updates, recreate the pod or use a sidecar that watches for changes. If using external secrets (Vault, AWS Secrets Manager), ensure the External Secrets Operator correctly maps remote keys to Kubernetes Secret keys.
No subnets found for EKS cluster
How to fix "eks subnet not found" in Kubernetes
unable to compute replica count
How to fix "unable to compute replica count" in Kubernetes HPA
error: context not found
How to fix "error: context not found" in Kubernetes
default backend - 404
How to fix "default backend - 404" in Kubernetes Ingress
serviceaccount cannot list resource
How to fix "serviceaccount cannot list resource" in Kubernetes