A pod references a Secret via secretKeyRef that doesn't exist, is in a different namespace, or has an incorrect key name. Fix by creating the missing Secret in the correct namespace, verifying key names match exactly (case-sensitive), or marking the reference as optional.
When a pod spec uses valueFrom.secretKeyRef to inject Secret data as an environment variable, Kubernetes resolves the Secret name and key at pod startup time. If the Secret doesn't exist, is in a different namespace, or doesn't contain the specified key, the pod cannot start. Secrets are namespace-scoped; there is no cross-namespace access mechanism. The error blocks pod creation entirely unless the reference is marked as optional. This is different from a pod that starts but doesn't receive the environment variable—the pod won't even begin startup.
Check all Secrets in the namespace:
kubectl get secrets -n <pod-namespace>
kubectl describe secret <secret-name> -n <pod-namespace>If the Secret doesn't appear, create it before the pod.
Examine the environment variable reference:
kubectl get pod <pod-name> -n <pod-namespace> -o yaml | grep -A5 secretKeyRefLook for:
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: db-secrets
key: passwordBoth name and key must match exactly (case-sensitive).
If the Secret doesn't exist:
kubectl create secret generic db-secrets \
--from-literal=username=admin \
--from-literal=password=secret123 \
-n <pod-namespace>Or with YAML:
apiVersion: v1
kind: Secret
metadata:
name: db-secrets
namespace: production
type: Opaque
stringData:
username: admin
password: secret123Secrets cannot be accessed across namespaces:
kubectl get secret <secret-name> -n <source-namespace> -o yaml | \
sed 's/namespace: <source-namespace>/namespace: <pod-namespace>/' | \
kubectl apply -f -To allow pod startup without the Secret:
env:
- name: OPTIONAL_SECRET
valueFrom:
secretKeyRef:
name: db-secrets
key: password
optional: trueWhen optional=true, pod starts even if Secret or key is missing.
Secrets referenced via secretKeyRef are blocking—pods won't start until the Secret is available. Use optional: true for non-critical secrets to prevent startup failures. Secret updates propagate to pods after ~1 minute (kubelet sync period). For externalized secret management, use External Secrets Operator to pull from Vault, AWS Secrets Manager, or Azure Key Vault. Avoid storing secrets in pod specs or ConfigMaps; use Secrets for sensitive data. Enable encryption at rest in etcd to protect secrets. RBAC should restrict which service accounts can read which secrets.
Failed to connect to server: connection refused (HTTP/2)
How to fix "HTTP/2 connection refused" error in Kubernetes
missing request for cpu in container
How to fix "missing request for cpu in container" in Kubernetes HPA
error: invalid configuration
How to fix "error: invalid configuration" in Kubernetes
etcdserver: cluster ID mismatch
How to fix "etcdserver: cluster ID mismatch" in Kubernetes
running with swap on is not supported
How to fix "running with swap on is not supported" in kubeadm