Configuration and StorageLesson 4.2

Kubernetes Secrets: storing sensitive data securely in a cluster

Secret types, base64 encoding vs encryption, Secret vs ConfigMap, Opaque secret, TLS secret, creating secrets from literals, secret injection methods, encryption at rest, RBAC for secrets

Secrets Are ConfigMaps for Sensitive Data

Kubernetes Secret injection warning diagram

Secrets store sensitive data — passwords, tokens, TLS certificates. The API and storage are the same as ConfigMaps, but Secrets signal intent and enable tighter RBAC controls.

Important: Secrets Are Base64, Not Encrypted

By default, Secrets in etcd are stored as base64 — not encrypted. Anyone with etcd access can decode them. Enable Encryption at Rest via EncryptionConfiguration, or use an external secrets manager (Vault, AWS Secrets Manager) with the External Secrets Operator.

Creating and Using Secrets

# Create from literal (values are auto-base64 encoded)
kubectl create secret generic db-creds   --from-literal=username=admin   --from-literal=password='S3cur3P@ss!'

# Or declaratively (you must base64 encode manually)
# echo -n 'admin' | base64  -> YWRtaW4=
apiVersion: v1
kind: Secret
metadata:
  name: db-creds
type: Opaque
data:
  username: YWRtaW4=
  password: UzNjdXIzUEBzcyE=

Injecting Secrets

containers:
- name: api
  env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-creds
        key: password
  volumeMounts:
  - name: creds-vol
    mountPath: /etc/secrets
    readOnly: true
volumes:
- name: creds-vol
  secret:
    secretName: db-creds