Cluster Hardening
Free Certified Kubernetes Security Specialist practice — 6 questions on Cluster Hardening, with explanations. No sign-up. Full 12-question mixed test →
A security audit finds that kubelet's read-only port 10255 is reachable from the pod network and returns detailed metrics and pod specs without any credentials. Which remediation correctly eliminates this exposure?
The read-only port (10255) has no authentication or authorization support whatsoever. The only correct fix is to disable it entirely (readOnlyPort: 0), forcing all API/metrics access through the secure port 10250 where authentication and authorization apply.
You need to harden kubelet's API so that unauthenticated requests are rejected and authorization decisions are delegated to the API server via SubjectAccessReview. Which kubelet configuration achieves this?
Disabling anonymous auth forces every request to be authenticated, and authorization.mode: Webhook delegates the access decision to the API server (via SubjectAccessReview), enforcing RBAC-based least privilege on the kubelet API.
Security policy requires that pods in the 'prod' namespace do NOT receive service account tokens by default, but the 'payment-api' Deployment must retain API access to watch ConfigMaps. Which approach satisfies both requirements with least privilege?
Kubernetes evaluates automountServiceAccountToken from the most specific scope: a pod-level (or dedicated ServiceAccount-level) setting of true overrides a namespace default ServiceAccount setting of false. This disables token mounting cluster-wide by default while explicitly re-enabling it only where needed.
A user's ClusterRole only grants get and list on pods. They attempt to create a ClusterRoleBinding that binds a separate, highly privileged ClusterRole (with * on *) to their own account. Which RBAC verb, if absent on the clusterroles/clusterrolebindings resources for this user, causes the API server's default privilege-escalation prevention to block this action?
The 'bind' verb specifically governs whether a subject can create a RoleBinding or ClusterRoleBinding that references a Role/ClusterRole granting permissions the subject does not already possess. Without 'bind' on roles/clusterroles, the API server's built-in escalation check rejects the binding.
An attacker compromises the kubelet credentials on worker-node-3 and attempts to use them to modify labels on worker-node-7, hoping to reschedule a malicious pod there via manipulated node affinity. Which control specifically prevents this cross-node action even though the compromised identity is a valid, authenticated kubelet?
The NodeRestriction admission controller limits kubelets (identities in the system:nodes group) to only modifying their own Node object and Pods bound to their own node, blocking any attempt to alter objects belonging to other nodes.
Since Kubernetes 1.24, what is the default behavior of service account tokens mounted into pods via the projected volume mechanism, and why does this reduce risk compared to the legacy pre-1.24 mechanism?
Bound service account tokens, requested via the TokenRequest API and mounted through a projected volume, are short-lived (1 hour default), scoped to specific audiences, and automatically refreshed by the kubelet before expiry — sharply reducing the blast radius if a token is exfiltrated, unlike the old non-expiring Secret-mounted tokens.
Ready for the real thing?
The full course has two full-length practice tests, video lessons for every exam domain, hands-on labs and detailed answer explanations.
Start my full course on Udemy →