mediumMultiple Choice
CKS Practice Question: Enable RBAC authorization and disable anonymous…
An administrator wants to enable RBAC authorization and disable anonymous authentication on the API server. Which set of flags should be added to the kube-apiserver configuration?
⚠ Common exam trap
Many exam-takers confuse admission controllers (like NodeRestriction) with authorization modes, or thinking that `--authorization-mode=Node` alone provides full RBAC, when it only handles node-specific authorization and must be combined with RBAC in a chain (e.g., `--authorization-mode=Node,RBAC`).
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
✓
--authorization-mode=RBAC --anonymous-auth=false
To enable RBAC authorization on the API server, you must set `--authorization-mode=RBAC`. Disabling anonymous authentication is achieved with `--anonymous-auth=false`, which prevents unauthenticated requests from being processed. Together, these flags enforce role-based access control and block anonymous access, meeting the administrator's requirements.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
--enable-admission-plugins=NodeRestriction --anonymous-auth=false
Why it's wrong here
The NodeRestriction admission plugin only limits what kubelet credentials may modify on Node and NodeStatus objects; it does not impose user-level authorization. Because --authorization-mode is omitted, the API server defaults to AlwaysAllow, so every authenticated request that passes the admission plugin is allowed to perform any action. Disabling anonymous auth alone removes unauthenticated connections, but it does nothing to prevent authenticated users or leaked ServiceAccount tokens from abusing full cluster-wide permissions.
- ✗
--authorization-mode=AlwaysAllow --anonymous-auth=false
Why it's wrong here
AlwaysAllow instructs the API server to approve every authenticated request without ever consulting Role-Based Access Control rules. Disabling anonymous authentication merely removes unauthenticated connections; any user or ServiceAccount with valid credentials remains completely unconstrained, effectively granting cluster-admin to every workload token. This configuration contradicts least-privilege and CIS hardening guidance because no RBAC predicate is evaluated, so a single compromised credential leads to full cluster compromise.
- ✓
--authorization-mode=RBAC --anonymous-auth=false
Why this is correct
Setting --authorization-mode=RBAC forces the API server to evaluate every request against Role, ClusterRole, RoleBinding, and ClusterRoleBinding rules before the requested operation is executed. Adding --anonymous-auth=false rejects requests that fail identity verification, closing the door to the system:anonymous user, which could otherwise be inadvertently bound to permissive roles. Together these flags enable the required authorization enforcement and align with the CIS Kubernetes Benchmark recommendation for the kube-apiserver.
- ✗
--authorization-mode=Node --anonymous-auth=true
Why it's wrong here
The Node authorizer is a special-purpose authorizer that only approves requests coming from kubelets—identified by system:node:* usernames and the Node group—for node-scoped operations such as reading pods or services bound to that specific node. It grants no general RBAC permissions for normal users, controllers, or ServiceAccounts, so it cannot enforce organization-wide policy. Additionally, --anonymous-auth=true allows completely unauthenticated requests to reach the API server and any endpoints the Node authorizer permits, making this setup insecure and unsuitable for the stated goal.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
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 →
Same concept, more angles
1 more way this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. An administrator wants to disable anonymous authentication to the Kubernetes API server. Which flag should be added to the kube-apiserver configuration?
medium- A.--disable-anonymous
- B.--authorization-mode=RBAC
- ✓ C.--anonymous-auth=false
- D.--enable-admission-plugins=DenyAnonymous
Why C: The `--anonymous-auth=false` flag explicitly disables anonymous authentication to the Kubernetes API server. When set to false, requests without valid authentication credentials are rejected with a 401 Unauthorized error, preventing unauthenticated access. This is the standard Kubernetes mechanism to disable anonymous authentication as documented in the kube-apiserver reference.
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.