Secrets Management

[!NOTE] This module explores the core principles of Secrets Management, deriving solutions from first principles and hardware constraints to build world-class, production-ready expertise.

1. Secrets vs ConfigMaps

They look identical (Key-Value pairs), but:

  1. Obfuscation: Secrets are Base64 encoded (Not encrypted by default!).
  2. RAM-backed: Secrets are stored in tmpfs (RAM) on the Node, never written to disk.
  3. RBAC: You can restrict who sees Secrets separately from ConfigMaps.

[!WARNING] Base64 is NOT Encryption. Anyone with kubectl get secret -o yaml can decode your secrets. In Production, enable Encryption at Rest in ETCD.

2. How to use Secrets?

Just like ConfigMaps:

  1. Env Vars: valueFrom: secretKeyRef.
  2. Files: Mount as volume at /etc/certs/.

3. Interactive: Base64 Decoder

Prove to yourself that Kubernetes Secrets are just encoded strings.

Kubernetes Secret "Encryption"

↓ Kubernetes Stores ↓
(Waiting for input...)
Run: echo -n 'PASSWORD' | base64

4. Production Patterns (GitOps)

You cannot check standard Secrets into Git (GitHub will scan and ban you).

1. Sealed Secrets (Bitnami)

  • Encrypt secret on laptop → SealedSecret (Safe to commit).
  • Controller in cluster decrypts it to Secret.

2. External Secrets Operator (ESO)

  • Store secrets in AWS Secrets Manager, Azure KeyVault, or HashiCorp Vault.
  • ESO operator syncs them into K8s Secrets automatically.

5. Code Example: Secret Manifest

Secret
Pod Usage
apiVersion: v1
kind: Secret
metadata:
  name: db-auth
type: Opaque
data:
  # echo -n 'admin' | base64 -> YWRtaW4=
  username: YWRtaW4=
  # echo -n 'p@ssword' | base64 -> cEBzc3dvcmQ=
  password: cEBzc3dvcmQ=

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  containers:
  - name: app
  image: my-app
  env:
  - name: DB_USER
    valueFrom:
    secretKeyRef:
      name: db-auth
      key: username
  - name: DB_PASS
    valueFrom:
    secretKeyRef:
      name: db-auth
      key: password