What is Kubernetes RBAC and How Does It Work?
Learn how Kubernetes RBAC grants access via Roles and RoleBindings, its deny-by-default model, and least-privilege design for an interview answer.
Expected Interview Answer
Kubernetes RBAC (Role-Based Access Control) is an authorization mechanism that grants subjects — users, groups, or service accounts — permission to perform specific verbs on specific resources by binding a Role or ClusterRole to that subject through a RoleBinding or ClusterRoleBinding.
A Role defines a set of rules scoped to a single namespace, each rule listing apiGroups, resources, and verbs such as get, list, watch, create, update, or delete; a ClusterRole is the same idea but scoped cluster-wide or reusable across namespaces. Neither a Role nor a ClusterRole grants anything on its own — it must be attached to a subject via a RoleBinding (namespace-scoped grant) or a ClusterRoleBinding (cluster-wide grant). The Kubernetes API server evaluates every request against these bindings and denies by default: if no rule explicitly allows the verb-resource combination, access is refused. This additive, deny-by-default model lets teams apply least-privilege access, for example granting a CI service account create/update rights only on Deployments in one namespace rather than blanket admin access.
- Enforces least-privilege access per namespace or cluster-wide
- Separates identity (subject) from permission (Role) via bindings, enabling reuse
- Deny-by-default reduces the blast radius of a compromised credential
- Auditable, declarative YAML that fits into GitOps workflows
AI Mentor Explanation
RBAC is like a stadium issuing role-specific accreditation passes instead of one master key to the ground. A groundskeeper pass permits entry to the pitch and covers only, a broadcaster pass permits camera positions only, and neither pass alone grants access — security checks the pass against a list before opening any gate. A team management staffer might be issued a pass valid across every ground the franchise plays at, which mirrors a cluster-wide grant rather than one limited to a single stadium. Without an issued pass matching the exact gate and purpose, security refuses entry by default, no exceptions assumed.
Step-by-Step Explanation
Step 1
Define a Role or ClusterRole
List apiGroups, resources, and verbs the rule should allow — scoped to a namespace (Role) or cluster-wide (ClusterRole).
Step 2
Identify the subject
A user, group, or ServiceAccount that needs the permission — service accounts are the common subject for workloads.
Step 3
Create a binding
A RoleBinding attaches a Role (or ClusterRole) to the subject within one namespace; a ClusterRoleBinding attaches it cluster-wide.
Step 4
API server enforces it
Every API request is authorized against the bound rules; anything not explicitly allowed is denied by default.
What Interviewer Expects
- Clear distinction between Role/ClusterRole (permissions) and RoleBinding/ClusterRoleBinding (grants)
- Understanding that RBAC is deny-by-default and additive-only
- Knowledge that ServiceAccounts are the typical subject for workload permissions
- Ability to describe least-privilege design, e.g. namespace-scoped Roles over broad ClusterRoles
Common Mistakes
- Confusing a Role with a RoleBinding, or assuming defining a Role alone grants access
- Using a ClusterRoleBinding when a namespace-scoped RoleBinding would suffice
- Forgetting that a ClusterRole can still be bound namespace-locally via a RoleBinding
- Granting wildcard verbs/resources instead of the specific minimum needed
Best Answer (HR Friendly)
“RBAC is how Kubernetes controls who can do what. We define a Role that lists specific permissions, then bind that Role to a specific user or service account. Nothing is allowed unless it is explicitly granted, which lets us give each team or automated process only the exact access it needs and nothing more.”
Code Example
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: staging
name: deployment-updater
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "update", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: ci-deploy-binding
namespace: staging
subjects:
- kind: ServiceAccount
name: ci-bot
namespace: staging
roleRef:
kind: Role
name: deployment-updater
apiGroup: rbac.authorization.k8s.ioFollow-up Questions
- What is the difference between a Role and a ClusterRole?
- How would you audit which ServiceAccounts have cluster-admin access?
- When would you use a ClusterRoleBinding instead of a RoleBinding?
- How does RBAC interact with admission controllers like OPA/Gatekeeper?
MCQ Practice
1. What does a Kubernetes Role define on its own?
A Role only defines rules; it grants no access until attached to a subject via a RoleBinding.
2. What is the default authorization behavior in Kubernetes RBAC when no rule matches a request?
RBAC is deny-by-default: any verb/resource combination not explicitly allowed by a bound rule is rejected.
3. Which binding type grants a ClusterRole's permissions only within a single namespace?
A RoleBinding can reference a ClusterRole to reuse its rule set but scope the grant to just one namespace.
Flash Cards
What does a Role define? — Allowed verbs on resources within a namespace — grants nothing until bound to a subject.
What links a Role to a user? — A RoleBinding (or ClusterRoleBinding for cluster-wide scope).
RBAC default behavior? — Deny by default — only explicitly allowed actions succeed.
Typical subject for workload permissions? — A Kubernetes ServiceAccount.