mediumMultiple Choice
CKS Practice Question: Auditing RBAC and find a ClusterRoleBinding named…
You are auditing RBAC and find a ClusterRoleBinding named 'admin-binding' that binds the 'cluster-admin' ClusterRole to the service account 'default' in namespace 'kube-system'. What is the risk?
⚠ Common exam trap
CNCF often tests the distinction between RoleBindings (namespace-scoped) and ClusterRoleBindings (cluster-scoped), and the trap here is that candidates mistakenly think a ClusterRoleBinding to a namespace-scoped service account is invalid or limited to that namespace.
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
✓
Any pod using the default service account in kube-system has cluster-admin privileges
The ClusterRoleBinding 'admin-binding' binds the 'cluster-admin' ClusterRole to the 'default' service account in the 'kube-system' namespace. Since ClusterRoleBindings are cluster-scoped, they grant permissions across all namespaces. Any pod in the 'kube-system' namespace that uses the 'default' service account (which is the default if no other service account is specified) will inherit cluster-admin privileges, allowing full control over the entire cluster.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The risk is only if the service account is used by external users
Why it's wrong here
The risk does not require any external user. The ClusterRoleBinding named 'a' grants cluster-admin to the 'default' service account in kube-system, and any pod that mounts that service account automatically obtains a token that authenticates to the Kubernetes API as that service account. Thus, a compromised or malicious container inside the cluster can leverage those elevated permissions without any external access. In fact, external users are not the threat; the threat is any API client using the service account's credentials, which includes in-cluster pods.
- ✗
The ClusterRoleBinding is invalid because it uses a namespace-scoped service account
Why it's wrong here
A service account is indeed a namespaced resource, but ClusterRoleBindings can legitimately reference service accounts as subjects, using the format 'serviceAccount:namespace:name'. The subject's namespace does not invalidate the binding; it simply identifies which service account receives the permissions. Since the permissions are cluster-scoped, this binding is valid and grants cluster-admin to that service account across the entire cluster. Far from being invalid, this configuration is a severe privilege risk.
- ✓
Any pod using the default service account in kube-system has cluster-admin privileges
Why this is correct
The ClusterRoleBinding 'a' assigns the cluster-admin ClusterRole to the 'default' service account in the kube-system namespace. Every pod scheduled into kube-system automatically mounts that service account's token unless automountServiceAccountToken is explicitly set to false. Using this token, a pod can authenticate to the Kubernetes API and has full administrative power: reading secrets, creating privileged pods, deleting nodes, and modifying RBAC policies. This effectively gives cluster-admin behavior to any workload running in that namespace without any additional authentication.
- ✗
No risk, as it is limited to kube-system namespace
Why it's wrong here
ClusterRoleBindings are cluster-scoped and their effects are not confined to the subject's namespace. Even though the service account lives in kube-system, the permissions granted by the binding apply across all namespaces and cluster-scoped resources. Therefore, a pod in kube-system can modify workloads in other namespaces, exfiltrate secrets from any namespace, or alter cluster-wide configuration. The 'kube-system' domain does not create a boundary; the binding still represents a cluster-wide compromise risk.
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
4 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. A ClusterRoleBinding named 'admin-binding' binds the cluster-admin ClusterRole to a service account 'sa-admin' in namespace 'ns1'. What is the security concern?
hard- ✓ A.The service account 'sa-admin' can access resources in all namespaces
- B.ClusterRoleBinding should be replaced by RoleBinding for cluster-scoped resources
- C.The service account token is automatically mounted
- D.ClusterRoleBinding should not be used for service accounts
Why A: A ClusterRoleBinding grants permissions cluster-wide, meaning the service account 'sa-admin' in namespace 'ns1' can access resources in all namespaces, not just its own. This violates the principle of least privilege by providing excessive access beyond the intended scope.
Variation 2. An administrator runs 'kubectl get clusterrolebindings' and notices a ClusterRoleBinding named 'admin-binding' that binds the 'cluster-admin' ClusterRole to a service account in the 'default' namespace. What security concern does this raise?
medium- ✓ A.The service account can now perform any action across all namespaces, which violates least-privilege.
- B.The service account can only access resources in the 'default' namespace.
- C.No concern; service accounts are allowed to have cluster-admin.
- D.The ClusterRoleBinding should be replaced with a RoleBinding.
Why A: A ClusterRoleBinding grants cluster-wide permissions, and the 'cluster-admin' ClusterRole provides superuser access to perform any action on any resource across all namespaces. Binding this to a service account violates the principle of least privilege because the service account gains unrestricted access to the entire cluster, including sensitive system resources, rather than being limited to only the permissions necessary for its function.
Variation 3. You are auditing RBAC and find a ClusterRoleBinding named 'admin-binding' that binds the 'cluster-admin' ClusterRole to a service account in the 'default' namespace. What is the security concern?
medium- A.The binding should be a RoleBinding instead of ClusterRoleBinding
- ✓ B.It grants too broad permissions to the service account
- C.The service account name must be changed
- D.The binding is fine as long as the service account is used in the default namespace
Why B: The 'cluster-admin' ClusterRole grants super-user permissions across the entire cluster, including access to all namespaces and all resources. Binding this role to a service account via a ClusterRoleBinding gives that service account unrestricted cluster-wide privileges, which violates the principle of least privilege. This is a significant security concern because if the service account is compromised, an attacker gains full control over the cluster.
Variation 4. A developer created a ClusterRoleBinding that grants cluster-admin to a service account. What is the security concern?
medium- A.Service accounts must use RoleBindings only
- B.ClusterRoleBindings are deprecated
- C.Service accounts cannot use ClusterRoleBindings
- ✓ D.It gives the service account full cluster-wide permissions, which is excessive
Why D: Granting a service account cluster-admin via a ClusterRoleBinding provides unrestricted, cluster-wide permissions, violating the principle of least privilege. This is a significant security risk as it allows the service account to perform any action on any resource in any namespace, including modifying RBAC rules, secrets, or node configurations. In Kubernetes, service accounts should be bound only to the minimal roles required for their function, typically using RoleBindings scoped to a specific namespace.
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.