Day 68: Secrets management — base64 isn't encryption
Doing better than base64-and-hope
From Day 53: Kubernetes Secrets are base64-encoded, not encrypted, by default — anyone with read access to that Secret (via RBAC) or direct etcd access can trivially recover the plaintext. Real secrets management needs two more layers: encryption at rest for etcd itself, and ideally, secrets that never live in Kubernetes as plaintext at all.
External Secrets Operator and Vault (Phase 26) let you store the actual secret in a dedicated secrets manager and sync only a reference (or a short-lived, dynamically generated credential) into the cluster — so a leaked Kubernetes manifest or a compromised Secret object doesn't hand over the actual long-lived credential.
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: db-creds
spec:
secretStoreRef:
name: vault-backend
target:
name: db-creds
data:
- secretKey: password
remoteRef:
key: secret/data/db
property: passwordKey terms
- Encryption at rest
- Encrypting etcd's stored data so raw disk/backup access doesn't expose Secret contents.
- External Secrets Operator
- Syncs secrets from an external secrets manager into Kubernetes Secrets, rather than storing them natively.
Why does syncing secrets from Vault via External Secrets Operator reduce risk compared to storing them natively as Kubernetes Secrets?
