Kubernetes RBAC Interview Questions

A Role is a namespaced RBAC resource, so the permissions it grants apply only inside the namespace where it is created. A ClusterRole is cluster-scoped, so it is not confined to any single namespace. It can define permissions that apply across all namespaces, or it can be referenced by a RoleBinding to grant those permissions within just one namespace. Because both halves of the statement hold, the statement is true.

A RoleBinding is a namespaced resource that grants the permissions defined in a Role, or in a ClusterRole, to specified subjects within that RoleBinding's namespace. A ClusterRoleBinding grants across all namespaces. ServiceAccount is an identity, not a binding. Role only defines permissions; it does not bind them to subjects.

A Role is the namespaced RBAC resource: its rules apply only within the namespace in which it is created. A ClusterRole is cluster-scoped and applies across the whole cluster. To grant a Role's permissions, you create a RoleBinding in that same namespace, or a RoleBinding that references a ClusterRole to scope it to one namespace.

Kubernetes RBAC has two role-resource types. A Role grants access to resources only in the namespace where it is created, while a ClusterRole grants access cluster-wide. A ClusterRole can also be referenced by a RoleBinding to apply its permissions within a single namespace, but the cluster-wide scope belongs to a ClusterRole used with a ClusterRoleBinding.

A ClusterRole is a set of rules with no namespace scope, so whether its permissions apply cluster-wide or in one namespace depends on the binding. A ClusterRoleBinding grants the ClusterRole's permissions across all namespaces, which is what is needed here. A RoleBinding that references a ClusterRole narrows the grant to the RoleBinding's own namespace, so a RoleBinding in the default namespace or in kube-system only grants access there. Kubernetes RBAC has no namespaceSelector field on RoleBinding, so that configuration cannot be expressed.

A Role is namespaced and contains the permission rules, so it fills the first blank. A RoleBinding is the namespaced object that connects those rules to specific subjects, so it fills the second blank. Without the RoleBinding, the Role's permissions are inert because no subject receives them until the binding exists.

A ClusterRole is cluster-scoped, but the binding that references it determines the effective scope. A RoleBinding that references a ClusterRole confines the granted permissions to the namespace the RoleBinding lives in, which lets one reusable role definition be applied per namespace. A ClusterRoleBinding is the object that grants a ClusterRole across all namespaces, and it has no namespace of its own. The other statements are wrong: a RoleBinding can reference a ClusterRole, a ClusterRoleBinding is cluster-wide rather than namespace-bound, and a ClusterRole is never created inside a namespace.

A Role or ClusterRole only defines a set of permission rules; it does not assign them to anyone. A RoleBinding is the object that links those rules to one or more subjects (users, groups, or ServiceAccounts) and scopes the grant to the namespace the RoleBinding lives in. A RoleBinding can reference either a Role or a ClusterRole, but in both cases the resulting access applies only within that namespace. The answer therefore centers on the RoleBinding's job of connecting permission rules to identities within a namespace.

This is true. A ClusterRole defines permissions that are not tied to a namespace, but when a namespace-scoped RoleBinding references it, the granted permissions apply only within the RoleBinding's namespace. This lets administrators define a reusable ClusterRole once and bind it in each namespace without duplicating the role. A ClusterRoleBinding, by contrast, applies the referenced ClusterRole across the whole cluster.

Kubernetes RBAC verbs map to API operations: get, list, watch, create, update, patch, delete, deletecollection, plus the wildcard *. The value read is not one of them, so a rule using it is invalid. Reading is expressed with get for a single object and list or watch for collections. The other three values, get, watch, and patch, are all standard verbs, so they are not the answer.

A RoleBinding may reference either a Role or a ClusterRole. When it references a ClusterRole, Kubernetes applies that ClusterRole's rules only within the RoleBinding's own namespace, which is the documented pattern for granting a cluster-defined role such as the built-in view role to one namespace. A ClusterRoleBinding applies its permissions across every namespace, which violates the requirement. A ClusterRole is cluster-scoped and cannot be created inside a namespace. A RoleBinding in kube-system would grant access in that namespace, not in dev.

A ServiceAccount subject needs its own kind: ServiceAccount plus separate name and namespace fields — that's how the binding resolves to the exact identity. kind: User with a bare report-generator never matches, because a ServiceAccount's actual authenticated username is the full system:serviceaccount:<namespace>:<name> string, not the bare name. kind: Group with batch:report-generator is malformed too — the real groups a ServiceAccount belongs to are system:serviceaccounts and system:serviceaccounts:<namespace>, not a <namespace>:<name> pair. And cramming the namespace into name (batch/report-generator) doesn't work either — namespace is always its own field on a ServiceAccount subject.

False. PSA replaced PodSecurityPolicy (removed in Kubernetes 1.25) — it did not replace RBAC. RBAC governs which identities can call which API verbs and resources (can this user or ServiceAccount create a Pod at all?); PSA governs what security posture a Pod's spec must have to be admitted into a namespace, checked regardless of who created it. A user with full RBAC rights to create Pods in a namespace can still be blocked by PSA if the Pod's securityContext doesn't meet the namespace's configured level. Both mechanisms remain necessary and operate independently — treating one as a substitute for the other leaves a real gap.

The ClusterRole pod-reader defines a reusable rule set granting get and list on pods. The RoleBinding pod-reader-binding is created in the staging namespace, references that ClusterRole, and binds the user alice. A RoleBinding is a namespaced object, so even when its roleRef names a ClusterRole, the grant only takes effect within the binding's own namespace. Therefore alice can get and list pods in staging only. A ClusterRoleBinding referencing the same ClusterRole would instead grant those permissions across all namespaces.

A RoleBinding grants the permissions of whatever role it references — including a ClusterRole — only within its own namespace; the binding, not the role object, determines the effective scope. Disabling default token automount prevents the kubelet from injecting a long-lived token into every Pod; explicitly provisioning a token via a projected TokenRequest volume or a service-account Secret lets you constrain the token's audience, lifetime, and rotation, which reduces exposure if a token leaks or a Pod is compromised.

kubectl auth can-i is the standard CLI for ad-hoc authorization checks. For the current caller it submits a SelfSubjectAccessReview, and the API server evaluates that request against the active authorization modules, including RBAC, and returns whether the action is allowed. Knowing the underlying SelfSubjectAccessReview resource matters for programmatic RBAC audits and for building policy tooling that checks permissions without reading Role bindings directly.

The Role pod-reader has two rules. The first grants get and list on the pods resource in the core API group (the empty string). The second grants get on the pods/log subresource, also in the core API group. The RoleBinding binds the ci-runner ServiceAccount to this Role in the staging namespace, so the ServiceAccount inherits exactly those permissions and nothing more. Creating a pod requires the create verb on the pods resource, and neither rule grants it. Because Kubernetes RBAC denies by default and permits only explicitly listed verbs, the API server returns 403 Forbidden for the create request. The ServiceAccount can read pods and their logs but cannot create, update, or delete them.

A RoleBinding that references a ClusterRole grants that ClusterRole's rules only within the RoleBinding's own namespace. The ClusterRole pod-reader grants get, list, and watch on pods, and the RoleBinding in the dev namespace binds it to the dev-sa service account. Because no ClusterRoleBinding is involved, the permissions do not extend beyond dev to other namespaces or to cluster-scoped resources.

A RoleBinding can reference either a Role or a ClusterRole. When it references a ClusterRole, the ClusterRole's rules are applied only within the RoleBinding's namespace, so the ServiceAccount gets the pod verbs (get, list, watch) only in the dev namespace. Granting that access across all namespaces would require a ClusterRoleBinding, not a RoleBinding. The ClusterRole grants only pod verbs, so access to other resource types is not granted. The claim that no permissions are granted is wrong because a RoleBinding can validly reference a ClusterRole.

The key insight is that Kubernetes RBAC subjects can be groups, not just individual ServiceAccounts. Every ServiceAccount is automatically a member of the built-in groups system:serviceaccounts and system:authenticated. A ClusterRoleBinding targeting either of those groups grants the bound ClusterRole's permissions cluster-wide to app-sa without any binding that references app-sa by name. A good answer names at least one of these group-based mechanisms and explains that the ClusterRoleBinding is what provides cluster-scoped access, since a RoleBinding would limit the grant to a single namespace.

A ClusterRole defines permissions at cluster scope, but those permissions only apply cluster-wide when attached through a ClusterRoleBinding. The ClusterRole granting get and list on pods, combined with a ClusterRoleBinding whose subject is the app-reader ServiceAccount in payments, grants read access to pods in all namespaces with no extra privileges. A RoleBinding, even one that references a ClusterRole, only applies within its own namespace, so the option pairing a ClusterRole with a RoleBinding in payments would limit access to that single namespace. A namespaced Role cannot be referenced by a ClusterRoleBinding, and a Role with a RoleBinding also stays confined to payments. Binding cluster-admin would work for reach but grants far more authority than needed, violating the narrowest-scope requirement.

The RoleBinding creation is denied. Alice's create permission on rolebindings only passes the normal authorization check for the RoleBinding object itself. Kubernetes then applies escalation prevention: a user may bind a Role only if they already hold all permissions that Role grants, or hold the bind verb on that Role or ClusterRole. Alice holds neither the bind verb on secrets-reader nor the get, list, or watch permissions on secrets, so the API server returns 403 Forbidden. The escalate verb is the wrong lever here because it applies to creating or editing Roles and ClusterRoles, not to binding an existing Role.

The system:masters group is special-cased in the kube-apiserver authorization chain. The API server checks for system:masters membership early in request processing and short-circuits all authorization checks, unconditionally allowing the request without consulting any RBAC RoleBindings or ClusterRoleBindings. The cluster-admin ClusterRoleBinding that references system:masters is effectively redundant — it exists for discoverability but does not grant the access; the access is hardcoded. Deleting it therefore has no effect. To genuinely restrict a system:masters member, an administrator must remove the user from the group at the identity-provider or authentication-config level, because no RBAC policy can override or narrow the hardcoded bypass.

By default Kubernetes RBAC prevents privilege escalation: when a principal creates or updates a Role or ClusterRole, the kube-apiserver verifies that the principal already holds every permission the new role grants, and returns 403 otherwise. The escalate verb on the roles (or clusterroles) resource is the documented escape hatch that bypasses this check, so a principal holding it can create a role containing permissions it does not itself have. The bind verb governs binding an existing role's permissions to subjects, not creating a role with new permissions. The impersonate verb lets one principal act as another user, and get is read-only. Neither of those bypasses the escalation check on role creation.

In the rbac.authorization.k8s.io/v1 API group, Role is the namespace-scoped resource for defining a named set of permission rules (verbs on API resources), and ClusterRole is its cluster-scoped counterpart. A RoleBinding grants the rules in a Role to subjects within a namespace, and a ClusterRoleBinding grants a ClusterRole's rules cluster-wide; a RoleBinding may also reference a ClusterRole to grant namespace-scoped access to otherwise cluster-level rules. Knowing which kind carries which scope is foundational to designing any multi-tenant RBAC model on Kubernetes.