CKS Cluster Hardening Practice Question
A company uses kube-bench to scan their cluster. The report shows a warning: 'Ensure that the --authorization-mode argument is set to Node,RBAC'. What is the best way to fix this?
⚠ Common exam trap
Watch out — candidates often think setting only `RBAC` is sufficient because it is the most common authorization mode, but the CKS exam specifically tests the requirement that `Node` must precede `RBAC` to handle node-level authorization correctly.
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
✓
Edit the kube-apiserver manifest to add --authorization-mode=Node,RBAC
Kube-bench checks that the API server's `--authorization-mode` includes both `Node` and `RBAC` in that order. The `Node` authorizer must come first to handle node-specific requests efficiently, followed by `RBAC` for user and service account authorization. Editing the kube-apiserver manifest (typically `/etc/kubernetes/manifests/kube-apiserver.yaml`) to add `--authorization-mode=Node,RBAC` ensures the static pod is automatically restarted by the kubelet with the correct configuration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add --authorization-mode=AlwaysDeny to the API server
Why it's wrong here
AlwaysDeny is not a valid authorization mode for the kube-apiserver in current Kubernetes versions; it was deprecated and removed. Even if it were accepted, AlwaysDeny would reject every API request, making the control plane unusable. The CIS benchmark and kube-bench require the Node and RBAC authorizers, not a blanket deny. You need to modify the kube-apiserver manifest to set --authorization-mode=Node,RBAC.
- ✗
Restart the API server with --authorization-webhook-config-file
Why it's wrong here
Configuring --authorization-webhook-config-file delegates authorization to an external webhook service, but the CIS baseline requires the built-in Node and RBAC authorizers to be active as well. The webhook is an additional authorizer for custom policy, not a replacement for the core modes. Removing Node and RBAC in favor of a webhook would break kubelet permissions and standard RBAC enforcement. Restarting with only the webhook config does not satisfy the kube-bench check.
- ✗
Set --authorization-mode=RBAC only
Why it's wrong here
Setting --authorization-mode=RBAC only omits the Node authorizer, which is specifically required to authorize kubelet API requests like pods, secrets, and nodes. The Node authorizer grants kubelets their narrow per-node permissions, while RBAC governs users, groups, and service accounts. Without Node mode, kubelet requests fall back to RBAC rules, which may not cover all node API paths and can cause authorization failures or require overly broad permissions. The correct flag is --authorization-mode=Node,RBAC.
- ✓
Edit the kube-apiserver manifest to add --authorization-mode=Node,RBAC
Why this is correct
Editing the kube-apiserver static manifest under /etc/kubernetes/manifests to add --authorization-mode=Node,RBAC is exactly what the CIS benchmark expects. This enables the Node authorizer for kubelet requests and the RBAC authorizer for all other identities, covering the two essential authorization paths. The kubelet will detect the manifest change and restart the API server as a static pod. This is the recommended configuration identified by kube-bench.
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
This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.