hardMultiple Choice
CKS Practice Question: A ClusterRoleBinding grants cluster-admin to a…
A ClusterRoleBinding grants cluster-admin to a service account in the 'kube-system' namespace. What is the best way to audit this for least privilege?
⚠ Common exam trap
Many candidates think simply listing or checking permissions (Options A or C) is sufficient for auditing, when the core requirement is to reduce permissions to the minimum necessary, which involves creating a custom Role.
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
✓
Review the permissions granted by cluster-admin and create a custom Role with only necessary permissions, then bind it.
The cluster-admin ClusterRole grants superuser access across all namespaces, which violates the principle of least privilege. The best practice is to review the specific permissions required by the service account, create a custom Role with only those necessary permissions, and bind it via a RoleBinding or ClusterRoleBinding scoped appropriately. This minimizes the attack surface and aligns with Kubernetes RBAC hardening guidelines.
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 'kubectl auth can-i --list' to check the service account's permissions.
Why it's wrong here
This command is diagnostic and will enumerate the effective permissions of the service account, but it does not alter any RBAC objects. While it can confirm the scope of the excessive cluster-admin grant, it provides no remediation. You must create a custom Role and binding to actually reduce privileges.
- ✗
Delete the ClusterRoleBinding immediately.
Why it's wrong here
Removing the ClusterRoleBinding outright is a blunt, irreversible action that would instantly revoke all administrative capabilities from the service account. Without first analyzing which API resources and verbs the workload genuinely requires, you risk causing widespread outages or losing the ability to manage the cluster entirely. A safer approach is to inspect the binding, identify the subject, and then create a scoped Role that preserves necessary operations.
- ✗
Run 'kubectl get clusterrolebindings' to list all bindings.
Why it's wrong here
Listing cluster role bindings only surfaces metadata such as the binding name, subjects, and referenced ClusterRole; it does not reveal the detailed permission rules or help you determine which permissions are excessive. To evaluate least privilege you need to inspect the ClusterRole definition (e.g., kubectl get clusterrole cluster-admin -o yaml) and cross-reference it with the service account's actual usage. Simply listing bindings is a discovery step, not a remediation strategy.
- ✓
Review the permissions granted by cluster-admin and create a custom Role with only necessary permissions, then bind it.
Why this is correct
The cluster-admin ClusterRole aggregates all core and custom resource permissions, including wildcard verbs and resources, and is intended for break-glass or node-level operations, not for routine service account workloads. By auditing the precise API resources and verbs the workload calls (e.g., using audit logs or kubectl auth can-i --list), you can construct a Role with minimal allow rules and bind it via a RoleBinding (for namespaced scope) or a ClusterRoleBinding (if truly cluster-scoped) limiting the subject to that service account. This aligns with the NIST least privilege principle and reduces the blast radius if the service account is compromised.
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 →
Same concept, more angles
5 more ways 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. Which TWO of the following are recommended actions to harden service account security in a Kubernetes cluster? (Select TWO)
medium- A.Delete all service accounts except the default one
- B.Use a single service account for all workloads
- ✓ C.Avoid granting cluster-admin ClusterRole to service accounts
- D.Grant cluster-admin to all service accounts for simplicity
- ✓ E.Disable automountServiceAccountToken for pods that do not require API access
Why C: Granting the cluster-admin ClusterRole to a service account provides unrestricted superuser access across the entire cluster, violating the principle of least privilege. The CKS exam emphasizes that service accounts should be bound only to the minimal RBAC permissions required for their function, and cluster-admin should never be used for routine workloads.
Variation 2. A security audit reveals that a service account 'monitor' is bound to the cluster-admin ClusterRole, which violates least-privilege. What is the best remediation?
medium- A.Delete the service account and recreate it without any role binding
- B.Keep the binding but add a Deny policy for write actions
- C.Set automountServiceAccountToken: false in the pod spec
- ✓ D.Create a new ClusterRoleBinding that binds 'monitor' to a less privileged role (e.g., view) and delete the cluster-admin binding
Why D: It directly addresses the violation of least-privilege by replacing the overly permissive cluster-admin ClusterRoleBinding with a binding to a more restrictive role like 'view'. This ensures the 'monitor' service account retains only the necessary read permissions, adhering to the principle of least privilege without disrupting its functionality.
Variation 3. A security audit reveals that a service account in the 'default' namespace has been granted cluster-admin privileges via a ClusterRoleBinding. What is the best mitigation?
medium- A.Disable the service account token automount
- B.Delete the service account
- ✓ C.Modify the ClusterRoleBinding to use a less privileged role
- D.Set --authorization-mode=AlwaysDeny
Why C: The best practice is to apply the principle of least privilege: instead of deleting the service account or disabling its token, you should modify the ClusterRoleBinding to bind the service account to a ClusterRole with only the permissions it actually needs. This retains the service account's functionality while removing excessive cluster-admin privileges, which grant unrestricted access to all cluster resources.
Variation 4. A pod runs with a service account that has a ClusterRoleBinding granting cluster-admin. What is the best practice to reduce the risk of privilege escalation?
medium- A.Use a PodSecurityPolicy to restrict the service account
- B.Delete the service account and create a new one without any roles
- ✓ C.Create a more restrictive Role/ClusterRole with only required permissions and bind it to the service account, removing the cluster-admin binding
- D.Add a NetworkPolicy to block outbound traffic from the pod
Why C: The principle of least privilege dictates that a service account should only have the permissions necessary for its function. By creating a more restrictive Role/ClusterRole with only required permissions and binding it to the service account, you remove the excessive cluster-admin privileges, directly reducing the risk of privilege escalation. This aligns with Kubernetes RBAC best practices for hardening cluster setup.
Variation 5. An administrator wants to ensure that no service account in the 'development' namespace has cluster-admin privileges. Which command should be used to identify such bindings?
medium- A.kubectl get serviceaccounts -n development
- ✓ B.kubectl get clusterrolebindings -o yaml | grep -B 10 namespace: development
- C.kubectl get rolebindings -n development --all-namespaces
- D.kubectl describe clusterrole cluster-admin
Why B: `ClusterRoleBindings` are cluster-scoped resources that grant permissions across all namespaces, including the `development` namespace. By piping the YAML output through `grep -B 10 namespace: development`, you can identify which `ClusterRoleBinding` references a service account in the `development` namespace, revealing any binding that could grant cluster-admin privileges to that namespace's service accounts.
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.