Articles
Kubernetes RBAC Interview Questions: Service Accounts, Bindings, and Privilege Escalation Risks
Prepare for Kubernetes RBAC interviews with ServiceAccount identity, binding scope, indirect privileges, and concrete allow-and-deny tests.
A deployment bot receives Forbidden, so an engineer proposes giving it cluster-admin for one release. The application may deploy, but the interview problem has become harder: can you identify the missing permission without granting control of every workload in the cluster?
Kubernetes RBAC questions reward precise reasoning about a request: who is making it, which API resource it targets, what verb it uses, and where the permission applies. The second layer is less obvious. A permission that sounds narrow can provide access to a more powerful identity or sensitive data through a workload.
Evidence boundary: Linked Kubernetes documentation supports the official platform rules below. The report-reader policy, permission ledger, and rollout tests are original defensive exercises, not candidate-reported interview questions or executed cluster experiments.
Start with Design secure Kubernetes with CI/CD. As you read, separate the permissions needed to release software from the permissions needed by the software itself. Those are different identities with different failure consequences.
How do you turn a Forbidden error into a precise question?
Official fact: Kubernetes authorization follows authentication and evaluates the attributes of an API request. Authorization is one stage in API access control; a successful authorization decision does not establish that all later processing will succeed. See Authorization.
Write down the request before editing policy. For an original report-reader scenario, the intended operation is:
system:serviceaccount:reports:reader → get → core/configmaps → reports/report-settings
That line is more useful than “the reader needs Kubernetes access.” It identifies the principal, verb, API group, resource, namespace, and object. If the failing client actually lists ConfigMaps, granting only get on one named object will not implement its current behavior.
Collect the error and the actual client context. A developer's successful command may use a personal administrator credential while the deployed process uses a ServiceAccount. Comparing those outcomes without comparing identities can send the investigation in the wrong direction.
Also distinguish resource access from application access. Permission to inspect a Service object does not authorize an HTTP request to the application behind it. RBAC governs Kubernetes API requests; your application and network controls have separate jobs.
What is the difference between an identity and its permissions?
Official fact: A ServiceAccount is a namespaced non-human identity. Kubernetes can provide its credentials to a Pod, and setting automountServiceAccountToken: false prevents automatic credential injection for that Pod. See Service Accounts.
Creating reports/reader does not explain what it can do. You must inspect the relevant role bindings and any other applicable grants. Conversely, deleting an unnecessary token mount does not remove every other way a workload might obtain credentials or reach an external service.
In the report-reader exercise, the application needs one configuration object and no deployment privileges. Give the workload its own identity so a later change to the release bot does not silently enlarge the application's authority. Name the owner of that identity and the reason each permission exists.
Ask whether the application needs the Kubernetes API at all. If configuration is supplied through an approved deployment mechanism, a continuously available API credential may be unnecessary. This is an architectural choice, not a reason to remove credentials blindly from an application that currently depends on them.
Does a ClusterRole always grant access across the cluster?
Official fact: Roles are namespaced; ClusterRoles are not. A RoleBinding can reference a ClusterRole while granting its applicable permissions within the binding's namespace. ClusterRoleBindings grant cluster-wide access. RBAC grants are additive and do not contain deny rules. See Using RBAC Authorization.
Here is the original scope ledger to explain aloud:
| Binding arrangement | Intended effect | Common mistaken conclusion |
|---|---|---|
Role in reports, RoleBinding in reports | Grant that role in reports | A similarly named identity in another namespace is the same principal |
ClusterRole with ConfigMap reads, RoleBinding in reports | Reuse those namespaced permissions in reports | The word ClusterRole automatically grants every namespace |
| ClusterRoleBinding to that ClusterRole | Grant the applicable access cluster-wide | It is equivalent to the previous row |
| Narrow RoleBinding plus an older broad binding | Effective access includes both grants | The narrower role overrides the broader grant |
That final row explains many failed cleanup efforts. Adding a more restrictive-looking role does not subtract the old grant. To demonstrate reduced access, identify all applicable bindings and test the intended denials after the change.
A useful follow-up asks where the ServiceAccount itself lives. A RoleBinding in the target namespace can refer to a ServiceAccount from another namespace. Keep subject namespace and permission scope separate in your explanation; they answer different questions.
Can you sketch a genuinely narrow permission?
For the report-reader exercise, assume the client fetches exactly one known ConfigMap by name. This illustrative policy expresses that requirement:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: report-settings-reader
namespace: reports
rules:
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["report-settings"]
verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: report-settings-reader
namespace: reports
subjects:
- kind: ServiceAccount
name: reader
namespace: reports
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: report-settings-reader
The example is deliberately limited to a named read. Do not copy it into a controller that discovers objects through a list/watch loop and then claim the client is broken. First establish the required API interaction and design a policy around it.
Review the example as a contract. Reading report-settings should succeed. Reading another ConfigMap should fail unless another grant permits it. Changing the object should fail. Accessing Secrets should fail. The binding should identify the intended ServiceAccount, not an entire broad group for convenience.
The interviewer may change the requirement to “read all report configurations as they change.” Explain why that changes the API operations and potentially the data exposure. A strong answer negotiates the requirement instead of adding a wildcard because the first test failed.
Why can workload creation be a privilege escalation risk?
Official fact: Kubernetes warns that permission to create workloads can indirectly expose namespace resources and ServiceAccount privileges. Sensitive capabilities also include certain role-management and impersonation permissions. See RBAC good practices.
The defensive implication is that a negative get secrets check is not a complete confidentiality proof. If a principal can control a workload that receives sensitive material, you must review that path too. Examine which identities and mounted resources the workload may use and which admission controls restrict its specification.
Consider an original review finding: a release bot cannot directly read Secrets, but it can change a Deployment in a namespace containing a powerful operational ServiceAccount. Before rating the finding, establish whether the bot can choose that identity, whether admission policy prevents it, and what the identity can actually access.
Describe the risk as a conditional chain, not an automatic cluster takeover. The impact depends on effective permissions and other enforced controls. A useful remediation might separate workload trust levels, restrict identity selection, or move a privileged controller out of the deployment namespace. Merely removing a direct Secret-read grant may leave the important path intact.
Official fact: Kubernetes restricts role and binding changes to prevent unauthorized escalation, with specific escalate and bind permissions affecting those checks. See RBAC escalation prevention. Do not conclude that any ability to create a RoleBinding automatically allows binding arbitrary administrative power.
How would you test least privilege without relying on one green command?
Official fact: kubectl auth can-i checks whether an action is allowed. Using --as requires permission to impersonate the specified identity. The command supports resource and subresource checks. See the can-i reference.
For an authorized reviewer, start with explicit requests:
kubectl auth can-i get configmaps/report-settings \
-n reports --as=system:serviceaccount:reports:reader
kubectl auth can-i update configmaps/report-settings \
-n reports --as=system:serviceaccount:reports:reader
kubectl auth can-i get secrets \
-n reports --as=system:serviceaccount:reports:reader
These commands are proposed checks, not results measured for this article. Record expected allow/deny outcomes before running them. If the reviewer lacks impersonation permission, use an approved test identity workflow rather than treating the failed impersonation as the application's authorization result.
Then run a controlled application operation using the real workload identity. Confirm both that necessary work succeeds and that unrelated operations remain denied. Include another namespace, another object, a write operation, and any relevant subresource in the test plan.
Official fact: Pod Security Admission can enforce Pod Security Standards independently of RBAC authorization. See Pod Security Admission. Therefore, can-i create pods returning yes does not certify that every proposed Pod specification will be admitted.
Keep the test report layered: API authorization, admission outcome, workload startup, and business operation. If deployment succeeds but the application cannot fetch configuration, you have proved the release identity worked, not the runtime identity.
How should a permission change be rolled out and explained?
Use an original before-and-after review record with four fields: required operation, existing grant path, proposed grant path, and acceptance evidence. For the report reader, the intended improvement is replacing unnecessary broad access with a named read while preserving successful configuration loading.
Capture current effective permissions before removing a binding. Exercise the change in an appropriate test environment, then observe the release with a defined rollback. A rollback should restore the specific prior grant when justified; “temporarily give cluster-admin” is not a bounded recovery plan.
Official fact: Kubernetes auditing records security-relevant API activity according to the configured audit policy. See Auditing. Use the available records to connect principal, request, resource, time, and outcome. Do not assume every cluster logs full request bodies, and avoid collecting credential contents just to prove access was denied.
A strong final explanation might be: “The bot's failing request was a Deployment patch in one namespace. I would test that exact operation, inspect all existing grant paths, and review whether workload control exposes stronger identities. I would verify required success and unrelated denial after the smallest justified change.”
Practice the request and the privilege boundary together
These verified question records offer adjacent Kubernetes and infrastructure practice. Their presence does not establish that the original interview included the specific RBAC exercise above.
| Interview question | RBAC follow-up to rehearse |
|---|---|
| Design secure Kubernetes with CI/CD | Separate release identity from runtime identity. |
| Compare cloud compute; design Kubernetes security and CI/CD | Explain namespace grants and indirect workload privilege. |
| Explain CI/CD, Kubernetes delivery, and troubleshooting | Diagnose one Forbidden request without a wildcard grant. |
| Explain How Microservices Run and Fail on Kubernetes | Distinguish API authorization from application connectivity. |
| Design a secure trading app on AWS | Compare Kubernetes permissions with external cloud identity boundaries. |
Continue with Design secure Kubernetes with CI/CD. Present the report-reader policy, then ask a partner to add one requirement. Explain the exact permission delta and one negative test that must still pass.