Overview
Minimize Microservice Vulnerabilities focuses on what runs inside the cluster. You label namespaces so Pod Security Admission enforces the Baseline or Restricted standard, then fix Pods that are rejected by adding runAsNonRoot, dropping capabilities and setting allowPrivilegeEscalation to false. You configure an EncryptionConfiguration so Secrets are encrypted in etcd, rewrite existing Secrets so they pick up the new provider, and verify the stored bytes with etcdctl. You isolate workloads with namespaces, quotas, NetworkPolicies and dedicated nodes, and run untrusted code in a sandbox such as gVisor or Kata Containers selected through a RuntimeClass.
The newest competency covers Pod-to-Pod encryption. Cilium can encrypt traffic transparently with WireGuard or IPsec, and Istio can enforce mutual TLS between sidecar-injected or ambient workloads with a PeerAuthentication policy in STRICT mode. Both projects' documentation is on the exam's allowed list.
How it's tested
Tasks here mix cluster configuration and workload edits. You might enforce Restricted in a namespace and repair a Deployment so its Pods are admitted, enable aescbc encryption for Secrets, create a RuntimeClass and move a Pod onto it, or enable strict mTLS in one namespace. Grading checks the stored data and the running Pods.
-
Admit the workload
A namespace enforces a Pod Security level and a Deployment shows zero ready replicas; you read the ReplicaSet events and add the missing securityContext fields.
-
Encrypt what is stored
You write an EncryptionConfiguration, wire it into kube-apiserver.yaml with a volume mount, then rewrite Secrets and confirm with etcdctl get that the value starts with k8s:enc.
-
Choose the isolation layer
A requirement mentions untrusted code, separate teams or encrypted traffic, and you pick between RuntimeClass, namespace controls, Cilium encryption or Istio PeerAuthentication.
A task enables encryption with providers aescbc then identity, and asks that all existing Secrets be encrypted. After the API server restarts, new writes use aescbc because the first provider encrypts, but old Secrets stay in plain text until rewritten. Running kubectl get secrets -A -o json piped to kubectl replace -f - rewrites them. Reversing the provider order would keep writing plain text.
Competencies 4
Official competencies from the CNCF / The Linux Foundation outline, in outline order.
4.1 Use appropriate pod security standardsPod Security Standards enforced through Pod Security Admission.
- What it means
- The Pod Security Standards define three levels: Privileged with no restrictions, Baseline blocking known privilege escalations, and Restricted following hardening best practice. The built-in Pod Security Admission controller applies them per namespace through labels.
- What to understand
- Label a namespace with pod-security.kubernetes.io/enforce, audit or warn set to a level, and optionally a matching -version label. Enforce rejects non-compliant Pods; audit records events; warn returns a message. Restricted requires runAsNonRoot, allowPrivilegeEscalation false, capabilities drop ALL, and a RuntimeDefault or Localhost seccomp profile. Enforcement applies to Pods, so Deployments are accepted while their Pods fail.
- How it shows up
- Expect to enforce a level on a namespace and repair a workload that the level blocks.
- Common confusion
- Assuming labelling a namespace evicts running Pods that violate the new level; it only affects new Pods.
4.2 Manage Kubernetes secretsSecret handling, access and encryption at rest.
- What it means
- Secrets hold credentials, but by default they are only base64-encoded in etcd. Managing them securely covers encryption at rest, limiting who can read them and how Pods consume them.
- What to understand
- Encryption at rest uses an EncryptionConfiguration passed with --encryption-provider-config; the first provider in the list encrypts new writes and all listed providers can decrypt. Providers include aescbc, aesgcm, secretbox and kms v2; identity means no encryption. Mount the config file into the API server static Pod. Verify with etcdctl get /registry/secrets/ns/name. Prefer volume mounts to environment variables, and restrict secrets access in RBAC.
- How it shows up
- A task may ask you to read a Secret's value, re-create it, or enable encryption and prove stored data is encrypted.
- Common confusion
- Treating base64 as encryption, or leaving identity first in the provider list.
4.3 Understand and implement isolation techniques (multi-tenancy, sandboxed containers, etc.)Separating tenants and running untrusted code safely.
- What it means
- Isolation limits the damage one workload or team can do to others. Soft multi-tenancy uses Kubernetes controls; stronger isolation adds a sandboxed runtime that puts an extra kernel boundary between a container and the host.
- What to understand
- Namespaces, RBAC, ResourceQuotas, LimitRanges and NetworkPolicies separate tenants. Taints, tolerations and node affinity can dedicate nodes. For untrusted code, a RuntimeClass names a handler configured in containerd, such as runsc for gVisor or kata for Kata Containers, and Pods select it with spec.runtimeClassName. gVisor intercepts syscalls in a user-space kernel; Kata runs each Pod in a lightweight virtual machine.
- How it shows up
- A task commonly asks you to create a RuntimeClass for an existing handler and run named Pods with it.
- Common confusion
- Expecting the RuntimeClass object to install gVisor; the handler must already exist on the node.
4.4 Implement Pod-to-Pod encryption (Cilium, Istio)Encrypting traffic between Pods in transit.
- What it means
- Pod-to-Pod encryption protects traffic inside the cluster network from interception. Cilium does this at the network layer, and Istio does it with mutual TLS between workload proxies.
- What to understand
- Cilium transparent encryption is enabled through its configuration, for example encryption.enabled with type wireguard or ipsec, and verified with cilium status or cilium-dbg encrypt status. Istio issues workload certificates and uses PeerAuthentication: PERMISSIVE accepts plain text and mTLS, STRICT accepts only mTLS. Sidecar mode requires namespace label istio-injection=enabled and Pod restarts.
- How it shows up
- Expect a task to make mTLS mandatory in one namespace or to confirm encryption is active.
- Common confusion
- Setting STRICT before workloads have proxies, which breaks their plain-text traffic.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Pod Security Admission labels
Namespace labels that set enforce, audit and warn levels.
- Remember
- pod-security.kubernetes.io/enforce=restricted rejects non-compliant Pods.
- Tested as
- Fastest way to apply a Pod Security Standard.
- Trap
- Expecting enforce to act on Deployments; it acts on Pods they create.
-
Restricted requirements
The strictest Pod Security level.
- Remember
- runAsNonRoot true, allowPrivilegeEscalation false, drop ALL capabilities, seccomp RuntimeDefault or Localhost.
- Tested as
- Repair tasks need all four.
- Trap
- Forgetting the seccomp profile, the item most often missed.
-
EncryptionConfiguration
API server config listing resources and encryption providers.
- Remember
- The first provider encrypts writes; the rest can only decrypt.
- Tested as
- Core of encryption at rest tasks.
- Trap
- Placing identity first, which writes plain text.
-
Rewriting existing Secrets
Forcing stored Secrets to be re-saved with the current provider.
- Remember
- kubectl get secrets -A -o json | kubectl replace -f -
- Tested as
- Without it only new Secrets are encrypted.
- Trap
- Checking a new Secret and assuming old ones changed.
-
etcdctl get on /registry
Reads the raw stored value of an object from etcd.
- Remember
- Encrypted Secrets begin with k8s:enc:aescbc:v1 or similar.
- Tested as
- Proves encryption works.
- Trap
- Running etcdctl without the TLS certificate flags.
-
RuntimeClass
Cluster object mapping a name to a container runtime handler.
- Remember
- Pods choose it with spec.runtimeClassName.
- Tested as
- Sandboxing tasks centre on this object.
- Trap
- Putting runtimeClassName in the container spec.
-
gVisor and Kata
Sandboxed runtimes adding a kernel boundary around containers.
- Remember
- gVisor uses a user-space kernel; Kata uses lightweight VMs.
- Tested as
- Answers 'run untrusted code more safely'.
- Trap
- Assuming they replace NetworkPolicies or RBAC.
-
PeerAuthentication STRICT
Istio policy requiring mutual TLS for inbound traffic.
- Remember
- Scope by namespace or workload selector; mesh-wide in the root namespace.
- Tested as
- Main Istio mTLS task.
- Trap
- Using DestinationRule alone and expecting servers to reject plain text.
-
Cilium transparent encryption
Network-layer encryption of Pod traffic with WireGuard or IPsec.
- Remember
- No sidecars; applies to traffic between Cilium-managed endpoints.
- Tested as
- Alternative answer to Pod-to-Pod encryption.
- Trap
- Expecting it to provide application identity like Istio mTLS.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Pod Security Admission modes
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| enforce | Rejects Pods that violate the level | Blocks creation | Overlooking that the Deployment still exists with zero Pods |
| audit | Records violations in audit log annotations | Allows the Pod | Expecting a message in kubectl output |
| warn | Returns a warning to the client | Allows the Pod and also checks workload templates | Taking a warning as proof the Pod was blocked |
Isolation and encryption options
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Namespace controls | RBAC, quotas and NetworkPolicies per tenant | Share the node kernel | Calling this strong isolation for hostile code |
| Sandboxed RuntimeClass | gVisor or Kata via runtimeClassName | Adds a kernel or VM boundary | Creating the RuntimeClass on a node without the handler |
| Cilium encryption | WireGuard or IPsec between nodes | Transparent, no proxies | Checking for sidecars to confirm it works |
| Istio mTLS | Proxy-to-proxy mutual TLS with workload identities | Enforced by PeerAuthentication | Leaving PERMISSIVE when STRICT was required |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Invisible rejection
- What candidates pick
- Concluding the Deployment applied successfully.
- Why it looks right
- kubectl apply reports created with no error.
- Why it's wrong
- Pod Security Admission blocks Pods at the ReplicaSet step, so errors appear in ReplicaSet events, not the apply output.
Clue to watch for READY 0/3 after a namespace has an enforce label.
-
Provider order
- What candidates pick
- Appending aescbc after identity.
- Why it looks right
- Adding a new provider at the end feels safer.
- Why it's wrong
- The first provider handles writes, so identity first means new Secrets stay plain text.
Clue to watch for A task asking that Secrets be encrypted, not just readable.
-
Config not visible
- What candidates pick
- Pointing --encryption-provider-config at a host path without a volume.
- Why it looks right
- The file exists on the node.
- Why it's wrong
- The API server runs in a container and cannot read host files unless they are mounted.
Clue to watch for API server fails to start with a file not found error.
-
Wrong isolation tool
- What candidates pick
- Adding a NetworkPolicy to contain untrusted code.
- Why it looks right
- Policies are familiar and quick to write.
- Why it's wrong
- Network rules do not protect the host kernel from a container escape; a sandboxed runtime does.
Clue to watch for Words such as untrusted, third-party or sandbox.
-
Half-enabled mTLS
- What candidates pick
- Setting PeerAuthentication STRICT in a namespace without sidecars.
- Why it looks right
- The policy is the visible requirement.
- Why it's wrong
- Workloads without proxies cannot present certificates, so traffic fails.
Clue to watch for Pods showing 1/1 containers in a namespace meant for Istio.
-
Base64 as protection
- What candidates pick
- Considering a Secret safe because its value is encoded.
- Why it looks right
- The data looks unreadable.
- Why it's wrong
- base64 -d decodes it instantly; protection comes from RBAC and encryption at rest.
Clue to watch for A task asking whether data is protected in etcd.
Answer framework
Work through these steps whenever a task asks you to protect a workload or its data.
- Classify the requirement as admission policy, Secret protection, tenant or runtime isolation, or traffic encryption before opening any file.
- Inspect the current state with namespace labels, ReplicaSet events, kube-apiserver flags, existing RuntimeClasses or mesh policies.
- Make cluster-level changes first, such as the EncryptionConfiguration, RuntimeClass or namespace labels, keeping a backup of any manifest you edit.
- Update the workload itself, adding securityContext fields, runtimeClassName or injection labels in the Pod template, and restart Pods so changes apply.
- Verify from the data path: Pods Running, etcdctl showing k8s:enc, the sandbox visible in Pod details, or mTLS status reported by the mesh tools.
Practice question
Want more like this? The CKS practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with Pod Security Admission because it is quick and links to several domains. Label a lab namespace restricted, deploy a plain nginx Deployment, read the ReplicaSet events and fix the template until Pods run. Keep a compliant securityContext snippet in your head so you can type it without docs.
Then rehearse encryption at rest end to end at least three times: generate a key with head -c 32 /dev/urandom | base64, write the config, add the flag, volume and volumeMount, wait for the API server, rewrite Secrets and check etcd. Time the whole sequence and aim for under twelve minutes.
For isolation, install gVisor on one lab node, configure the runsc handler in containerd and run a Pod with a RuntimeClass. Read the Istio PeerAuthentication page and the Cilium transparent encryption page on the allowed documentation sites, and if time allows, install each once with default settings so their status commands are familiar.
FAQ
How much is Minimize Microservice Vulnerabilities worth on the CKS?
It is weighted at 20% of the score, tied with Supply Chain Security and Monitoring, Logging and Runtime Security as the heaviest domains. Expect three or four tasks.
Are PodSecurityPolicies still tested?
No. PodSecurityPolicy was removed in Kubernetes v1.25. The current competency refers to Pod Security Standards, enforced by the built-in Pod Security Admission controller or by external policy engines.
Which encryption provider should I choose?
Use what the task specifies. Without guidance, aescbc or aesgcm with a local key is typical in exam scenarios, while kms v2 is preferred in production because the key stays outside the cluster.
Do I need to install Istio or Cilium during the exam?
Installing either from scratch would take most of a task's time. Expect them to be present and to configure policies or settings, using the Istio and Cilium documentation the Linux Foundation allows.
What makes gVisor different from a normal container runtime?
gVisor's runsc runs a user-space kernel that handles most syscalls itself, so a container rarely talks to the host kernel directly. That reduces the impact of kernel exploits at some performance cost.
Should Secrets be passed as environment variables?
Volume mounts are generally preferred because environment variables can leak through crash dumps, logs or child processes. Exam tasks may ask you to convert one to the other.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 4 knowledge
Run timed tasks on Pod Security Admission, Secret encryption, sandboxed runtimes and mTLS to confirm the 20% domain is under control.