CKA Secret Objects and Mounting Meets CKS Encryption-at-Rest, External Stores, and Short-Lived Credentials
The Certified Kubernetes Administrator exam asks whether you can get a secret into a pod. The Certified Kubernetes Security Specialist exam asks whether that secret is encrypted where it rests, scoped to who needs it, and short-lived enough to survive a leak. Secrets management is where those two questions meet, and it spans two CKS domains — Cluster Hardening and Minimize Microservice Vulnerabilities — plus the CKA Workloads objective.
This is the exam-prep face of today's Ops lesson. The Ops lesson argued for leased, rotating, tightly-scoped credentials in the abstract; this one shows the exact Kubernetes objects and commands that implement them. Same discipline — issue short, rotate often, contain the blast — expressed as Secret resources, an EncryptionConfiguration, an external secret store, and projected ServiceAccount tokens with an expiry.
A Kubernetes Secret is a namespaced object holding key-value data, base64-encoded in the manifest. Base64 is encoding, not encryption — this is the single most-tested misconception. Anyone who can read the object reads the secret; the protection comes from RBAC on the object and encryption at rest underneath it, not from the base64.
A pod consumes a Secret two ways, and the exam expects you to know the tradeoff. As environment variables, which are simple but leak into child processes, crash dumps, and kubectl describe output, and do not update when the Secret changes. As a mounted volume, where each key becomes a file and — crucially — the kubelet updates the mounted files when the Secret changes, without restarting the pod. For a rotating secret, mount it; the volume path is the rotation-friendly one.
apiVersion: v1
kind: Pod
metadata: { name: agent, namespace: agents }
spec:
serviceAccountName: agent-sa # identity used to fetch tokens
containers:
- name: app
image: registry.internal/agent@sha256:9f86d0...
volumeMounts:
- name: db-cred
mountPath: /var/run/secrets/db # files update on Secret change
readOnly: true
volumes:
- name: db-cred
secret:
secretName: db-credential
defaultMode: 0400 # owner read-onlyNote defaultMode: 0400 and readOnly: true: the CKS instinct is least privilege even on the mount. The file is owner-read-only, the mount is read-only, and the image is pinned by digest (the supply-chain habit from 07-01). The mounted-volume choice is what lets an external rotation update /var/run/secrets/db under the running container — the cluster-side version of the Dev lesson's silently-refreshed token.
By default a Secret is stored in etcd in plaintext (base64). Anyone with etcd access — a node backup, a snapshot, a compromised control-plane host — reads every secret in the cluster. CKS Cluster Hardening requires you to configure encryption at rest so etcd holds ciphertext. This is done with an EncryptionConfiguration referenced by the API server's --encryption-provider-config flag.
# /etc/kubernetes/enc/enc.yaml (referenced by kube-apiserver)
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources: ["secrets"]
providers:
- aescbc: # a real encrypter FIRST = encrypt on write
keys:
- name: key1
secret: <base64 32-byte key>
- identity: {} # plaintext fallback for reads only, LASTProvider order is the whole exam question. The API server writes with the first provider and can read with any listed provider. Put a real encrypter (aescbc, or kms for an external key) first so new writes are encrypted; keep identity last so already-plaintext secrets stay readable during migration. Reverse the order and you write plaintext. After enabling it, existing secrets are still plaintext until re-written — the canonical migration command is kubectl get secrets --all-namespaces -o json | kubectl replace -f -, which rewrites every secret through the now-encrypting provider.
A native Secret still lives in the cluster and does not rotate itself. The production pattern the exam increasingly reflects moves the source of truth outside Kubernetes and leases credentials in. Three mechanisms carry it.
ESO watches an external store (Vault, cloud secret manager) and syncs values into native Secrets via an ExternalSecret resource. Rotation at the source propagates to the mounted volume, and the pod picks up new files with no restart.
Mounts secrets straight from an external store into the pod as a volume, so the value need never become a native etcd Secret at all — the tightest blast radius, since the cluster never persists the plaintext.
A ServiceAccount token projected with an expirationSeconds and an audience is a true lease: the kubelet rotates it under the pod before it expires. This is the Kubernetes-native short-lived credential.
The projected ServiceAccount token is the cleanest example of the Ops lesson's lease living inside Kubernetes, and it is directly testable:
volumes:
- name: sa-token
projected:
sources:
- serviceAccountToken:
path: token
audience: vault # token only valid for this consumer
expirationSeconds: 3600 # kubelet rotates BEFORE expiry
The audience scopes the token to a single consumer, so a leaked token cannot be replayed against a different service — that is blast-radius scoping. The expirationSeconds makes it a lease the kubelet renews under the running container, which the app reads fresh from the file each time. Together they are exactly the Ops lesson's short-lived, tightly-scoped, auto-rotated credential, expressed in a pod spec. The app never rotates anything; it re-reads the file, the same way the browser re-reads its in-memory token.
Read the two exams as one lifecycle. CKA gets the secret into the pod — object, mount, mode. CKS makes that safe end to end: encrypted at rest with the key outside the cluster (Cluster Hardening), scoped by RBAC so only the right ServiceAccount reads it (the 06-24 lesson), and leased short with projected tokens or an external store (Minimize Microservice Vulnerabilities). The Ops lesson is the why; this lesson is the how; the Dev lesson is the same lease one tier out in the browser. The trivy-scan-and-cosign-verify habits from 07-01 still apply to the image that mounts the secret — a trusted secret in an untrusted image is no defense.
A teammate says the cluster's secrets are safe because they are base64-encoded in the manifests. State precisely why that is wrong, and name the two mechanisms that actually protect a Secret's confidentiality.
An EncryptionConfiguration lists identity first and aescbc second. Encryption at rest appears configured but etcd still holds plaintext for newly created secrets. Explain why, and give the corrected provider order.
A Secret backs a database password that an external operator rotates hourly. The pod consumes it as an environment variable and keeps authenticating with the old password after rotation. What is the root cause, and which consumption method fixes it without a pod restart?
Write the intent of a projected serviceAccountToken volume that (a) expires in one hour and (b) cannot be replayed against a service other than vault. Name the two fields that enforce each property.
You enable encryption at rest with a valid EncryptionConfiguration, but a etcdctl dump still shows old secrets in plaintext. Why are the existing secrets unaffected, and what single command re-encrypts them all?
Encoding is not encryption; a mounted volume rotates where an env var does not; the encrypting provider goes first and the key belongs outside the cluster; and a projected token with an audience and an expiry is a lease the kubelet renews for you. Those four facts are most of what CKA and CKS ask about secrets, and they are the same four moves the Ops lesson made in the abstract.
In the exam and in production, reach for the shortest-lived, tightest-scoped credential the platform will give you, and let the kubelet or the external store do the rotating. The secret you never persist in plaintext and never let outlive its audience is the one that survives a leaked etcd snapshot without becoming an incident.