CKA + CKS — Admission Controllers, Pod Security Standards, and Secrets Encryption at Rest

Two exams, one shared cluster ground, three operator competencies.

§ IFrame

The CKA and CKS exams are paired on Wednesday because they share an operating ground. Both ask the candidate to operate a Kubernetes cluster from the command line under time pressure; both grade hands-on work; both use the same kubectl, the same manifest formats, the same cluster topology. CKA covers cluster administration breadth: workload management, networking, storage, troubleshooting. CKS layers security on top: admission control, runtime security, supply-chain integrity, secrets handling.

Today's combined lesson treats the shared cluster ground once and pivots between CKA-flavor and CKS-flavor application. The topic (admission control, Pod Security Standards, secrets encryption at rest) sits at the intersection where CKA's workload-management surface meets CKS's security-policy surface. Mastery of this topic answers cluster-admin questions on the CKA and security-policy questions on the CKS without context-switch.

The framing also reinforces today's Ops and Dev lessons. The Ops lesson described the cluster-side mechanism: admission webhooks, ValidatingAdmissionPolicy, External Secrets Operator. The Dev lesson described the application-side discipline: secrets.compare_digest, Fernet, scope. This cert-prep lesson lifts the same body of knowledge into exam-readiness, showing how the exam graders test the underlying mechanisms.

§ IIDomain Foundations (shared cluster ground)

Three areas form the shared cluster ground for both exams.

The admission control pipeline (exam framing)

Both CKA and CKS test admission control, but at different depths. CKA candidates must know that mutating admission runs before validating admission, that the kube-apiserver flag --enable-admission-plugins= configures the built-in pipeline, and that common plugins (ResourceQuota, LimitRanger, NamespaceLifecycle, PodSecurity) are enabled by default in current Kubernetes versions. CKS candidates extend this to write ValidatingWebhookConfiguration resources, debug failing admission webhooks, and design admission policies that enforce specific security postures.

The exam-readiness target is to read a MutatingWebhookConfiguration or ValidatingWebhookConfiguration YAML and identify the rules, the failurePolicy, the timeoutSeconds, the matchPolicy, the namespaceSelector, and the objectSelector. The rules block names the API groups, versions, resources, and operations the webhook applies to. The failurePolicy decides what happens when the webhook is unreachable (Fail or Ignore), and getting this wrong is a common exam-trap because Fail means the webhook becoming unreachable blocks all matching requests cluster-wide. Production posture favors Fail for security-critical webhooks (a missing security check should block deploys, not silently pass them) and Ignore for non-critical mutation.

Pod Security Standards in exam context

PSS has fully replaced the older PodSecurityPolicy (PSP, removed in 1.25). CKA candidates must know how to label a namespace with the three keys (pod-security.kubernetes.io/enforce, pod-security.kubernetes.io/audit, pod-security.kubernetes.io/warn) and the three levels (privileged, baseline, restricted). CKS candidates must additionally know what each level allows and denies: restricted denies privilege escalation, requires runAsNonRoot: true, denies host namespaces, denies hostPath volumes, requires seccomp profile (RuntimeDefault or Localhost), and constrains capabilities to drop ALL and add only NET_BIND_SERVICE.

A frequent exam task: given a failing pod in a restricted-labeled namespace, identify which restricted rule it violates and modify the pod spec to comply. The grader is looking for the candidate to recognize the violation pattern (the pod runs as root, or mounts hostPath, or sets capabilities the level disallows) and fix the spec, typically by adding a securityContext block with runAsNonRoot: true, runAsUser: 1000, allowPrivilegeEscalation: false, capabilities: { drop: ["ALL"] }, and seccompProfile: { type: RuntimeDefault }.

Secrets at rest

A Kubernetes Secret is base64-encoded in etcd by default. The cluster operator enables real encryption via an EncryptionConfiguration file pointed at by kube-apiserver's --encryption-provider-config= flag. The file declares one or more resources blocks, each listing the resource type to encrypt and an ordered list of providers (kms, aescbc, aesgcm, secretbox, identity). The first provider in the list is used to encrypt; all providers in the list are tried in order on decrypt.

CKA candidates must know how to enable encryption (write the config, restart kube-apiserver, run kubectl get secrets -A -o json | kubectl replace -f - to re-encrypt existing Secrets with the new provider). CKS candidates extend this to design the provider chain, typically KMS first (the production-grade choice; routes encryption decisions through an external key-management service), then identity for graceful fallback during migration.

The exam-readiness check: given a cluster with encryption at rest enabled via KMS, walk through the encrypt-and-decrypt path. The kube-apiserver writes a Secret; it generates a per-Secret data encryption key (DEK); it asks the KMS plugin to encrypt the DEK with the key encryption key (KEK) held by KMS; the encrypted DEK is stored alongside the AES-encrypted Secret content in etcd. On read, the kube-apiserver retrieves the encrypted DEK from etcd, asks KMS to decrypt it (which produces the plaintext DEK), then uses the DEK to decrypt the Secret content. Disk access to etcd alone gives no plaintext; an attacker would also need KMS-access to the KEK.

§ IIICKA Flavor (cluster administration emphasis)

CKA's admission-control questions sit at the cluster-operator level. The candidate is asked to enable a built-in admission plugin via the kube-apiserver static-pod manifest at /etc/kubernetes/manifests/kube-apiserver.yaml. The edit is to the --enable-admission-plugins flag's value, adding the plugin name to the comma-separated list. The kubelet detects the manifest change and restarts the kube-apiserver pod. The candidate verifies with kubectl get --raw='/livez/admission' or by attempting an action the plugin should block.

A common CKA task: configure ResourceQuota in a namespace, then deploy a pod that violates the quota, and confirm the API server rejects it. The task tests both the ResourceQuota admission plugin and the candidate's ability to read kubectl error output (exceeded quota: cpu, requested: ..., used: ..., limited: ...). The exam grader is looking for the candidate to recognize the quota-exceeded error and adjust either the pod request or the quota.

Another common CKA task: enable encryption at rest. The candidate writes an EncryptionConfiguration file (typically /etc/kubernetes/enc/enc.yaml), edits the kube-apiserver manifest to mount the file and add --encryption-provider-config=/etc/kubernetes/enc/enc.yaml, restarts the API server (the kubelet handles this on manifest change), and re-encrypts existing Secrets. The grader checks that new Secrets are encrypted in etcd (verifiable via ETCDCTL_API=3 etcdctl get /registry/secrets/... showing ciphertext) and that the cluster continues to function.

CKA candidates should also be fluent with the PodSecurity admission plugin (compiled in, enabled by default) and the namespace-label mechanism described above. A typical task: label a namespace with pod-security.kubernetes.io/enforce: restricted and confirm that a privileged pod cannot be created in that namespace.

§ IVCKS Flavor (security policy emphasis)

CKS's admission-control questions push deeper. The candidate writes a ValidatingWebhookConfiguration resource that points to an in-cluster webhook service implementing OPA Gatekeeper, Kyverno, or a custom admission server. The exam-readiness target is to write the YAML by memory: rules block, clientConfig.service, caBundle, admissionReviewVersions: [v1], sideEffects: None, timeoutSeconds: 5. The failurePolicy choice is often the implicit grading criterion; getting it right (Fail for security-critical) signals operator-discipline.

The CKS exam may ask the candidate to write a Kyverno ClusterPolicy that enforces a specific posture: require images from a specific registry, deny privileged containers, require liveness probes. The YAML is Kyverno-specific (apiVersion: kyverno.io/v1, kind: ClusterPolicy, spec.rules containing match selectors and validate blocks with pattern or deny clauses). The candidate must know the Kyverno DSL well enough to write a working policy under time pressure.

Pod Security Standards on CKS go deeper into the why. The candidate may be asked which PSS level allows hostPort but denies hostNetwork (answer: baseline allows hostPort with a bounded range; restricted denies both). Or why runAsNonRoot: true alone is insufficient (because the runtime could still launch a process that exec's into root after start; the level also requires allowPrivilegeEscalation: false to be safe).

Encryption at rest on CKS layers in KMS provider configuration and key rotation. The candidate may be asked to rotate the KEK without downtime; the operational path is to add a new KMS provider as the first entry in the EncryptionConfiguration's provider list (so it becomes the encrypt-with provider), keep the old provider in the list (so existing ciphertexts still decrypt), restart kube-apiserver, re-encrypt existing Secrets with the new provider, then optionally remove the old provider from the list. The candidate is graded on understanding that the provider list order controls encrypt-with (first) versus can-decrypt-with (all).

§ VWorked Practice Scenario

The exam scenario: a cluster has been deployed without encryption at rest, with the default PodSecurity plugin but no namespace labels, and with no admission webhooks. The candidate's task in 25 minutes:

1. Enable AES-CBC encryption at rest with a fallback to identity for migration.
2. Label all non-system namespaces with pod-security.kubernetes.io/enforce: baseline and the production namespace with pod-security.kubernetes.io/enforce: restricted.
3. Re-encrypt existing Secrets.
4. Install Kyverno (Helm or manifest; provided in the exam environment).
5. Write a Kyverno ClusterPolicy that requires images to come from registry.k8s.io or docker.io/library.
6. Deploy a test pod with an image from a disallowed registry; confirm it is rejected.

The exam-readiness path:

# Step 1 (encryption config at /etc/kubernetes/enc/enc.yaml + kube-apiserver flag edit)
# Step 2
kubectl label namespace prod pod-security.kubernetes.io/enforce=restricted
for ns in $(kubectl get ns -o jsonpath='{.items[?(@.metadata.name!="kube-system")].metadata.name}'); do
  kubectl label namespace $ns pod-security.kubernetes.io/enforce=baseline --overwrite
done
# Step 3
kubectl get secrets -A -o json | kubectl replace -f -
# Step 4 (Helm install or manifest apply)
# Step 5 (write Kyverno ClusterPolicy YAML)
# Step 6 (kubectl apply test pod, verify rejection)

Time budget breakdown for the exam: step 1 takes ~7 minutes (config file + manifest edit + restart wait + verification), steps 2-3 ~4 minutes, step 4 ~3 minutes, step 5 ~7 minutes (the Kyverno YAML is the hardest part to write from memory), step 6 ~2 minutes. The grader checks each step's artifact (the EncryptionConfiguration, the namespace labels, the Kyverno policy, the rejected pod's API server error message).

§ VIConnection to Today's Ops + Dev Lessons

The Ops lesson described the same admission-control and ESO surface from the cluster-operator perspective; this cert lesson recasts it as exam-readiness. The Dev lesson described the consumer-side handling of credentials once they arrive in the pod; the cert exams test the cluster-side path that gets them there. The trio coheres because the trust posture spans all three surfaces: the cluster encodes the rules (Ops + Cert), the credential pipe respects them (Ops), the application consumes safely (Dev).

The convergence is operational, not coincidental. A real production cluster needs all three competencies. The Wednesday lesson trio gives them in one breath.

Paired Ops → Archmagus-Stack/β-Trust/Synthesis-Lessons/2026-05-27-kubernetes-admission-control-and-external-secrets-operator-defense-in-depth-for-trust-coupled-workloads

Paired Dev → Polyglot-Dev/Python/2026-05-27-pythons-secrets-module-and-cryptography-library-for-trust-coupled-workloads

§ VIIPractice Questions

§ VIIIClosing

The CKA + CKS Wednesday pairing sits naturally with today's Ops β-Trust focus because admission control, Pod Security Standards, and secrets encryption at rest are the exact ground where cluster administration meets cluster security. Master this ground and both exams test the same competencies in different framings. The discipline carries through to production work; the exam-readiness habits (read the YAML carefully, know the failure modes, time the steps) are operator-discipline habits at a faster cadence.

Walk a request through admission. Walk a Secret through encryption at rest. Walk a pod through restricted PSS. The walks are the audit; the audit is the exam; the exam is the production day at faster pace.