CKS Practice Question 3: RBAC Workload Creation Escalation
Certified Kubernetes Security Specialist (CKS) · Test 1 · question 3 of 10
In the team-a namespace, a developer is bound to a Role that grants create, update, and delete on deployments only, no access to secrets, serviceaccounts, or any cluster-scoped resource. The same namespace contains a ServiceAccount named ci-deployer that a ClusterRoleBinding has bound to cluster-admin.
During a threat-modelling exercise you are asked what this combination allows. Which statement describes the real exposure?
Show answer and explanation
Answer:
Permission to create workloads in a namespace implicitly grants the API access of *any* ServiceAccount in that namespace, because a Pod template may name any of them and the kubelet will mount that ServiceAccount's token into the container. The developer writes a Deployment that runs a shell, reads /var/run/secrets/kubernetes.io/serviceaccount/token, and now holds cluster-admin. Workload creation rights are therefore equivalent to the strongest ServiceAccount in the namespace, the reason the RBAC good-practice guidance treats them as a privilege escalation risk and warns against keeping powerful ServiceAccounts alongside ordinary developer namespaces.
Option A inverts how this works. Pods authenticate as their ServiceAccount, not as the user who created them; the API server performs no re-evaluation against the creator's rights once the object is admitted.
Option B misuses escalate. That verb governs whether a subject may grant permissions they do not themselves hold when creating or updating a Role, which is not what happens here, and the escalation described needs no Secret access at all.
Option C is simply false. bind and escalate are distinct verbs on roles/clusterroles in the rbac.authorization.k8s.io API group; holding update on Deployments confers neither, and the developer cannot create bindings.
Reference: Role Based Access Control Good Practices