CKS Cluster Hardening Practice Question
Which TWO of the following are valid ways to restrict access to the Kubernetes API server?
⚠ Common exam trap
CNCF often tests the distinction between authentication (who you are) and authorization (what you can do), so candidates may confuse RBAC (authorization) with authentication mechanisms like webhook tokens, but the question asks for ways to 'restrict access,' which includes both authentication and authorization controls.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use webhook token authentication
Webhook token authentication (Option B) is a valid method to restrict API server access because it delegates token validation to an external service via a webhook, allowing custom authentication logic. This is a supported authentication strategy in Kubernetes, enabling fine-grained control over who can access the API server.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use static token file
Why it's wrong here
A static token file stores plaintext bearer tokens in a CSV on the control-plane node. These tokens cannot be individually revoked without rotating the entire file, and they are transmitted as raw credentials, making them vulnerable to interception and theft. Kubernetes has deprecated this mechanism because it offers no per-user expiration, no integration with external identity providers, and no audit trail for token issuance, so it is not a recommended way to restrict cluster access.
- ✓
Use webhook token authentication
Why this is correct
Webhook token authentication offloads token validation to an external webhook service, such as an OIDC provider, custom authentication server, or policy engine. When a user presents a token, the API server sends a TokenReview to the webhook endpoint and applies the returned status, allowing dynamic validation, immediate revocation, and integration with enterprise SSO. This is a secure and flexible authentication method that can be combined with RBAC to enforce fine-grained authorization after a user’s identity is reliably established.
- ✗
Enable NodeRestriction admission plugin
Why it's wrong here
The NodeRestriction admission plugin is an admission controller that limits the kubelet’s ability to create or modify resources, restricting it to nodes and pods bound to its node name. It does not govern how API server clients authenticate or authorize; it only limits what the kubelet can do after it has already been authenticated. Therefore, enabling it does not restrict access for human users, service accounts, or other clients, making it irrelevant to the goal of controlling general cluster access.
- ✓
Configure RBAC authorization
Why this is correct
RBAC (Role-Based Access Control) is the standard authorization mode in Kubernetes, used to determine whether an authenticated user or service account is allowed to perform a requested action. It lets administrators define Roles and ClusterRoles, bind them to subjects via RoleBindings and ClusterRoleBindings, and thereby enforce least-privilege access—for example, allowing a developer to read pods in a namespace but not delete deployments. RBAC is a valid and essential way to restrict access because it ensures that even authenticated users only have the permissions they actually need.
- ✗
Enable anonymous access
Why it's wrong here
Enabling anonymous access allows unauthenticated requests to reach the API server, effectively bypassing the authentication layer. If RBAC policies happen to grant permissions to the `system:anonymous` user or `system:unauthenticated` group, these requests can perform actions without any credentials, which creates a severe security risk. It should only be enabled when intentionally exposing public information, and it is not a mechanism for restricting access; it is the opposite of a secure access control measure.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 845 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.