Kubernetes Secrets
Store sensitive data (passwords, tokens) base64-encoded, mounted as env or files.
ContainersIntermediate
Why
Secrets store sensitive data separately from image and ConfigMap. They're base64-encoded (not encrypted by default) and can be mounted as env vars or files.
Docker is used by 59% of professional developers per the Stack Overflow 2024 survey, and Kubernetes runs 60% of containerized workloads in production (CNCF 2024 survey). Container orchestration reduces deployment-related incidents by 35% through declarative rollouts.
When
Use Secret for passwords, API keys, TLS certs. Enable encryption at rest for real security.
How
1. Create — kubectl create secret generic --from-literal
2. From file — --from-file=tls.crt
3. Encode — base64 values in YAML
4. Mount — env.valueFrom.secretKeyRef or volume
5. Encrypt — enable encryption at rest
6. External — ExternalSecrets or Vault
7. Rotate — update secret, rollout restart
Example
# Create secret
kubectl create secret generic db-secret --from-literal=password=supersecret --from-literal=user=admin
# Or via YAML (base64 encoded)
apiVersion: v1
kind: Secret
metadata: { name: db-secret }
type: Opaque
data:
password: c3VwZXJzZWNyZXQ= # base64 of "supersecret"
user: YWRtaW4= # base64 of "admin"
# Use in deployment
spec:
containers:
- name: app
env:
- name: DB_PASSWORD
valueFrom: { secretKeyRef: { name: db-secret, key: password } }
Common Problems
- ⚠Secrets not encrypted at rest — base64 only, enable encryption in etcd
- ⚠Secrets in git — never commit Secret YAML, use sealed-secrets or ExternalSecrets
- ⚠Configuration drift between environments — use infrastructure-as-code (Terraform/Pulumi) to keep dev/staging/prod identical
Best Practices
- ✓Enable encryption at rest — encrypts secrets in etcd, not just base64
- ✓Use ExternalSecrets or Vault — keeps secrets out of git, managed externally
- ✓Set up health checks and graceful shutdown — handle SIGTERM to drain in-flight requests before exit