RBAC Interview Questions

A Role grants permissions within a single namespace, while a ClusterRole grants permissions cluster-wide or across all namespaces. ClusterRoles are also required for non-namespaced resources like Nodes and PersistentVolumes.

A RoleBinding grants permissions within a specific namespace by binding a Role or ClusterRole to subjects. A ClusterRoleBinding grants permissions cluster-wide by binding a ClusterRole to subjects across all namespaces.

RBAC (Role-Based Access Control) is the standard authorization mechanism in Kubernetes. It lets you define fine-grained permissions by creating Roles that specify allowed API actions and binding them to users, groups, or ServiceAccounts.

Every namespace has a default ServiceAccount that is automatically assigned to Pods without an explicit serviceAccountName. If RBAC bindings are added to the default ServiceAccount, every Pod in that namespace inherits those permissions, creating an over-privileged attack surface.

You create a Role by defining rules that specify API groups, resources, and allowed verbs in a YAML manifest. You then create a RoleBinding that associates the Role with a subject (user, group, or ServiceAccount). Both can be created declaratively with YAML or imperatively with kubectl.

kubectl auth can-i checks whether a specific action is allowed by RBAC. You can test your own permissions or impersonate another user or ServiceAccount to verify their access. It is the primary CLI tool for RBAC debugging.

A ServiceAccount is an identity for processes running inside Pods. Kubernetes automatically mounts a token for the Pod's ServiceAccount, and RBAC bindings grant that ServiceAccount specific API permissions. Every namespace has a default ServiceAccount.

Least privilege means granting only the minimum RBAC permissions required for a subject to perform its function. This involves creating narrow Roles with specific verbs and resources, using namespace-scoped bindings, disabling unused ServiceAccount tokens, and regularly auditing permissions.

RBAC troubleshooting follows a systematic approach: verify the denial with kubectl auth can-i, check existing bindings and roles, inspect audit logs for the exact request, and fix the gap by creating or updating the appropriate Role and Binding.

Aggregated ClusterRoles use label selectors to automatically combine rules from multiple ClusterRoles into a single ClusterRole. Kubernetes built-in roles (admin, edit, view) use aggregation, allowing CRD authors to extend them without modifying the originals.

Kubernetes does not manage user accounts internally. Authentication is handled by external systems — X.509 client certificates, OIDC tokens, webhook token authentication, or cloud IAM. After authentication establishes identity, RBAC uses that identity (username and groups) to authorize API requests.

RBAC achieves namespace isolation by granting teams permissions only within their designated namespaces using namespace-scoped RoleBindings, avoiding ClusterRoleBindings, locking down the default ServiceAccount, and preventing cross-namespace resource access. Combined with NetworkPolicies and ResourceQuotas, this creates a multi-tenant boundary.