Overview
Cluster Hardening narrows access to the API server. You audit Roles and ClusterRoles for wildcards and dangerous verbs, replace broad bindings with namespace-scoped ones, and confirm the result with kubectl auth can-i. You stop Pods from mounting tokens they never use by setting automountServiceAccountToken to false, create dedicated service accounts with only the permissions an application needs, and avoid granting anything to the default service account. On the API server you remove anonymous access where possible, keep --authorization-mode at Node,RBAC, enable admission plugins such as NodeRestriction, and stop exposing the API on a NodePort.
The last competency is routine but security-driven: upgrading a kubeadm cluster to a supported patch or minor release so known CVEs are closed. The upgrade sequence is the one you learned for the CKA, now framed as vulnerability management.
How it's tested
Hardening tasks usually start from an over-permissive state you must reduce. A service account may hold a ClusterRoleBinding it should not, a Deployment may mount a token it never uses, or the API server may allow anonymous requests. The grader checks the final objects and flags, and sometimes confirms that a legitimate action still works.
-
Reduce, do not remove
An application must keep one capability, such as reading ConfigMaps in its namespace, while every other permission is taken away; deleting the binding outright fails the task.
-
Token exposure
A Pod or service account mounts an API token unnecessarily, and you disable automounting on the right object without breaking a workload that needs it.
-
API server flag change
You adjust kube-apiserver.yaml to disable anonymous auth, remove a NodePort exposure or enable an admission plugin, and confirm the API returns.
A task says service account reporter in namespace finance must only get and list Pods there, but it currently holds a ClusterRoleBinding to view. Deleting the ClusterRoleBinding and creating a Role with get and list on pods plus a RoleBinding in finance meets both halves. Editing the view ClusterRole would change permissions for every other subject bound to it, which the task did not ask for.
Competencies 4
Official competencies from the CNCF / The Linux Foundation outline, in outline order.
2.1 Use Role Based Access Controls to minimize exposureAuditing and narrowing RBAC grants.
- What it means
- RBAC is the main authorization mechanism in Kubernetes. Minimizing exposure means each user and service account holds only the verbs and resources it needs, in the narrowest scope, with no shortcuts like wildcards or cluster-admin.
- What to understand
- Review grants with kubectl get rolebindings,clusterrolebindings -A -o wide and kubectl auth can-i --list --as=system:serviceaccount:ns:name. Treat get, list or watch on secrets as sensitive, and treat escalate, bind, impersonate and create on pods/exec as privilege paths. Members of system:masters bypass authorization entirely. Prefer a Role plus RoleBinding over cluster-wide grants unless cluster-scoped resources are required.
- How it shows up
- A task asks you to remove excess rights from a subject while keeping one named action working.
- Common confusion
- Thinking list on secrets is harmless because get is missing; list returns the Secret data too.
2.2 Exercise caution in using service accounts e.g. disable defaults, minimize permissions on newly created onesDedicated service accounts and controlled token mounting.
- What it means
- Every namespace has a default service account, and Pods use it unless told otherwise. A service account token mounted into a Pod lets any process in it call the API with that account's rights.
- What to understand
- Set automountServiceAccountToken: false on the default service account, or on a Pod spec, which takes precedence over the account setting. Create a named service account per workload and grant it a minimal Role. Since Kubernetes v1.24, token Secrets are no longer created automatically; Pods get short-lived, audience-bound tokens through a projected volume, and kubectl create token issues one on demand.
- How it shows up
- Expect to create a service account with no automounted token and attach it to an existing Deployment.
- Common confusion
- Setting the field in the Deployment metadata instead of spec.template.spec.
2.3 Restrict access to Kubernetes APIAPI server authentication, authorization and exposure.
- What it means
- Restricting API access means only authenticated, authorized clients on expected networks reach the kube-apiserver. It covers anonymous requests, authorization modes, admission plugins and how the API endpoint is published.
- What to understand
- Check --anonymous-auth, --authorization-mode (Node,RBAC, never AlwaysAllow) and --enable-admission-plugins including NodeRestriction in kube-apiserver.yaml. The insecure HTTP port was removed in v1.20, so do not look for it. If the kubernetes Service in default has been changed to NodePort, set it back to ClusterIP. User access is granted with client certificates signed through a CertificateSigningRequest and bound with RBAC.
- How it shows up
- A task may ask you to disable anonymous access or remove an external exposure of the API, then confirm kubectl works.
- Common confusion
- Disabling anonymous auth can affect liveness probes that hit unauthenticated endpoints; check the API server stays healthy.
2.4 Upgrade Kubernetes to avoid vulnerabilitiesKeeping clusters on supported, patched releases.
- What it means
- Kubernetes publishes security fixes in patch releases for the three most recent minor versions. Running an unsupported or unpatched version leaves known CVEs open, so upgrading is a security control.
- What to understand
- Follow the kubeadm order: upgrade the kubeadm package, run kubeadm upgrade plan and apply on the first control plane node, kubeadm upgrade node on others, then drain, upgrade kubelet and kubectl, restart kubelet and uncordon. Upgrade one minor version at a time. Worker nodes follow the control plane, and the kubelet may lag the API server but must never be newer.
- How it shows up
- You may be told to bring a control plane and one worker to an exact patch version.
- Common confusion
- Skipping a minor version, which kubeadm refuses, or forgetting to uncordon the node afterwards.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
kubectl auth can-i
Checks whether a subject may perform a verb on a resource.
- Remember
- Use --as and -n, and --list to print every permission a subject holds.
- Tested as
- The fastest way to prove an RBAC change worked.
- Trap
- Testing as yourself and forgetting --as.
-
Dangerous verbs
escalate, bind and impersonate allow a subject to gain rights beyond its own grants.
- Remember
- Create on pods, pods/exec or workloads can also lead to privilege escalation.
- Tested as
- Audit tasks expect you to spot these in a Role.
- Trap
- Focusing only on delete as the risky verb.
-
system:masters
A group that bypasses RBAC authorization checks.
- Remember
- Credentials in this group cannot be restricted by removing bindings.
- Tested as
- Explains why some admin certificates remain all-powerful.
- Trap
- Trying to limit it with a Role.
-
automountServiceAccountToken
Field on a ServiceAccount or Pod spec controlling whether a token is mounted.
- Remember
- The Pod-level value overrides the ServiceAccount value.
- Tested as
- Core of every service account hygiene task.
- Trap
- Setting it on the Deployment's top-level spec, where it is ignored.
-
Bound service account tokens
Short-lived, audience-scoped tokens delivered through projected volumes.
- Remember
- Since v1.24 legacy token Secrets are not auto-created; kubectl create token issues one.
- Tested as
- Shows why deleting a token Secret may not revoke Pod access.
- Trap
- Expecting every service account to have a Secret listed.
-
NodeRestriction
Admission plugin limiting kubelets to modifying their own Node and Pods bound to it.
- Remember
- Pair it with --authorization-mode Node,RBAC.
- Tested as
- Appears in benchmark and API hardening tasks.
- Trap
- Thinking it secures the kubelet's own port.
-
Anonymous authentication
Requests without credentials are treated as system:anonymous.
- Remember
- --anonymous-auth=false on the API server rejects them outright.
- Tested as
- A common hardening flag in exam tasks.
- Trap
- Assuming RBAC alone stops anonymous users when someone bound them.
-
Version skew and support
Kubernetes supports the three newest minor releases with patches.
- Remember
- Upgrade minor versions one step at a time, control plane first.
- Tested as
- Frames the upgrade competency as CVE management.
- Trap
- Upgrading the kubelet to a version newer than the API server.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Ways to remove excess permissions
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Delete the binding | Removes all rights the binding gave the subject | Also removes rights the subject still needs | Breaking the application the task said must keep working |
| Replace with a Role and RoleBinding | Grants exactly the required verbs in one namespace | Leaves other subjects unaffected | Forgetting the namespace on the binding |
| Edit a shared ClusterRole | Changes rules for every subject bound to it | Has cluster-wide side effects | Editing built-in roles such as view or edit |
Service account token controls
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| automountServiceAccountToken on ServiceAccount | Default behaviour for Pods using that account | Overridden by the Pod setting | Expecting it to apply to Pods already running |
| automountServiceAccountToken on Pod | Controls mounting for that Pod only | Wins over the account value | Placing it outside spec.template.spec in a Deployment |
| Dedicated service account | A named account per workload with minimal rights | Keeps permissions out of the default account | Binding the new account to cluster-admin for convenience |
| kubectl create token | Issues a short-lived token for an account | Does not create a stored Secret | Treating the output as permanent |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Over-removal
- What candidates pick
- Deleting every binding for the service account.
- Why it looks right
- It guarantees no excess permissions remain.
- Why it's wrong
- The task also requires a named action to keep working, and the grader tests it.
Clue to watch for Phrases such as 'must still be able to'.
-
Pods keep old tokens
- What candidates pick
- Updating the service account and checking an existing Pod.
- Why it looks right
- The account change looks complete.
- Why it's wrong
- Mount settings apply when a Pod is created, so running Pods keep their tokens until recreated.
Clue to watch for A task that says the Deployment must use the new setting.
-
Wrong authorization mode
- What candidates pick
- Adding RBAC after AlwaysAllow in the mode list.
- Why it looks right
- It seems to enable RBAC without removing anything.
- Why it's wrong
- Authorizers are consulted in order, and AlwaysAllow approves every request before RBAC is reached.
Clue to watch for Benchmark findings about --authorization-mode.
-
Secret list blind spot
- What candidates pick
- Granting list on secrets while denying get.
- Why it looks right
- Get sounds like the verb that reads content.
- Why it's wrong
- A list response includes the full data of every Secret in scope.
Clue to watch for A requirement to read Secret names only.
-
Skipping minor versions
- What candidates pick
- Upgrading straight from two minor versions back to the target.
- Why it looks right
- It looks faster on paper.
- Why it's wrong
- kubeadm supports only one minor step per upgrade, and it refuses the jump.
Clue to watch for A target version more than one minor release ahead.
Answer framework
Use this sequence for access-reduction tasks so you remove risk without breaking required behaviour.
- Record what the subject can do now with kubectl auth can-i --list --as and note which bindings grant it.
- Separate the required permissions named in the task from everything else and write the minimal Role or ClusterRole they need.
- Create the new Role and binding first, then delete or narrow the over-broad binding, so nothing needed is lost midway.
- For token or API server changes, edit the Pod template or manifest, then recreate Pods or wait for the static Pod to restart.
- Verify both directions: the required action returns yes and a forbidden action, such as listing secrets, returns no.
Practice question
Want more like this? The CKS practice test has questions for every domain.
Checklist
0 of 10
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Spend the first sessions on RBAC drills. Create service accounts, grant them a deliberately excessive ClusterRoleBinding, then reduce access to a single verb and test it from both sides with kubectl auth can-i. Generate objects with kubectl create role and rolebinding plus --dry-run=client -o yaml so you only edit what the generator cannot express.
After that, practise token hygiene. Toggle automountServiceAccountToken at the account and Pod level, recreate Pods and inspect /var/run/secrets/kubernetes.io/serviceaccount to see when a token appears. Read the kubernetes.io page on service account administration once so the projected token behaviour makes sense.
Then review kube-apiserver.yaml line by line on a kubeadm cluster and explain each security-relevant flag aloud. Finally, run one full kubeadm patch upgrade under a timer, since the steps are long and easy to misorder under pressure. Keep a short written list of the upgrade commands and compare it with the kubernetes.io page after each run, so gaps in your memory show up before the exam does. Aim to finish an RBAC reduction task in about four minutes.
FAQ
What share of the CKS exam is Cluster Hardening?
Cluster Hardening is weighted at 15% in the official CNCF curriculum, the same as Cluster Setup. That usually means two or three tasks, often quick RBAC or service account changes.
Do I need to know the CKA upgrade procedure again?
Yes. The upgrade competency reuses the kubeadm workflow, and the kubernetes.io upgrade page is allowed during the exam. Know the order well enough that the page only confirms package versions.
Should I disable the default service account?
You cannot delete it permanently because the controller recreates it. Disable token automounting on it and give each workload its own account instead.
Is anonymous authentication always safe to turn off?
It removes unauthenticated access, which the benchmark recommends. Some health checks rely on anonymous access to endpoints like /livez, so confirm the API server stays Ready after the change.
How do I find who can read Secrets in a namespace?
Use kubectl auth can-i get secrets -n ns --as for suspect subjects, or search Roles and ClusterRoles for secrets rules and trace their bindings with kubectl get rolebindings -o wide.
Are certificate signing requests part of this domain?
Restricting API access includes how users authenticate, so creating a CertificateSigningRequest, approving it and binding the user with RBAC is fair preparation, though the competency does not name it.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 2 knowledge
Practise RBAC reduction, service account token and API server hardening tasks against the clock to find where you lose time.