Secrets

What a Secret Actually Provides

Secrets store sensitive data — passwords, TLS keys, tokens — as base64-encoded key-value entries:

kubectl create secret generic db-creds \
  --from-literal=username=app \
  --from-literal=password='s3cr3t'

Base64 is encoding, not encryption: anyone who can kubectl get secret -o yaml decodes it instantly. Real protection comes from three layers — etcd encryption at rest (a separate configuration), RBAC limiting who may read secrets at all, and keeping Secrets out of Git and pod logs.

Like ConfigMaps they are namespace-scoped and capped near 1 MiB, with well-known types such as Opaque, kubernetes.io/tls, and kubernetes.io/dockerconfigjson for registry credentials.

Injecting Secrets

Two standard patterns:

spec:
  containers:
  - name: app
    env:
    - name: DB_PASSWORD
      valueFrom: { secretKeyRef: { name: db-creds, key: password } }
    volumeMounts:
    - { name: creds, mountPath: /etc/db, readOnly: true }
    imagePullSecrets:
    - { name: regcred }
  volumes:
  - name: creds
    secret: { secretName: db-creds, items: [{ key: password, path: password }] }

Mounted files materialize as real files on disk (mode 0644 by default, tunable via defaultMode), which suits apps expecting a keyfile. Env injection is simpler but leaks into /proc and child processes. Projected volumes can merge a Secret, a ConfigMap, and a service account token into one mount.

Pitfalls and Interview Angles

Pitfall 1 — treating base64 as security. Without encryption at rest, the data sits readable in etcd; enable an encryption provider (covered in the encryption topic) and restrict get/list on secrets with RBAC.

Pitfall 2 — stale mounted secrets. Updates propagate to mounted files in about a minute, but apps cache them; env vars never update. Rotate by changing the Secret, then rolling the workload to restart.

Interview-ready: state plainly that Secrets are base64 plus RBAC plus optional etcd encryption — not envelope crypto by default — explain imagePullSecrets for private registries, and name the hardening moves: disable automountServiceAccountToken where unused, and use short-lived projected tokens instead of long-lived static secrets.