Kubernetes Secrets Management
Kubernetes Secrets are widely misunderstood. The built-in Secret resource stores values as base64 — encoding, not encryption — and by default lands in etcd as plaintext. Anyone with etcd read access or an etcd backup can read every Secret in the cluster. The three production strategies for hardening secrets are: etcd encryption-at-rest (EncryptionConfiguration with KMS envelope encryption), External Secrets Operator (pull secrets from AWS Secrets Manager, GCP Secret Manager, Vault, or Azure Key Vault into K8s Secrets at sync time), and CSI/Vault Agent injection (secrets never enter etcd at all, mounted directly into pods as files). GitOps-safe patterns include Sealed Secrets (asymmetrically encrypted blobs safe to commit) and SOPS (Mozilla, in-place encrypted YAML values). Understanding which pattern fits which threat model is a core platform engineering competency.
Sign up free to read the full topic
More DevOps topics
- Kubernetes Observability: Metrics, Logs, and Traces
- Kubernetes Operators & CRDs
- Kubernetes Pod Networking & CNI
- Kubernetes Pod Scheduling
- Kubernetes RBAC
- Kubernetes Runtime Classes
- Kubernetes Security: Pod Security and Runtime Hardening
- Kubernetes Services
- Kubernetes Storage
- Kubernetes the Hard Way
- Kubescape and Kubernetes Runtime Security
- Kustomization and Reconciliation
Start free on Cariara · Coding problems · System design studio