RBAC

Role-Based Access Control (RBAC) is Kubernetes’ built-in authorization mechanism that determines what actions users and applications can perform within your cluster. Think of RBAC as a building’s access card system—each person gets a card that grants access only to the floors and rooms they need for their work.

Core Concepts

RBAC controls access by defining who can do what to which resources. It uses four main building blocks:

• Roles - Define permissions within a namespace
• RoleBindings - Grant role permissions to users or groups within a namespace
• ClusterRoles - Define permissions across the entire cluster
• ClusterRoleBindings - Grant cluster-wide permissions to users or groups

How RBAC Works

When a request comes to the Kubernetes API, the authorization process follows these steps:

The API server checks:

1. Who is making the request (user, ServiceAccount, or group)
2. What action they’re trying to perform (get, list, create, update, delete, etc.)
3. Which resource they’re targeting (pods, services, deployments, etc.)
4. Where the resource is located (namespace-scoped or cluster-scoped)

Why RBAC Matters

Without RBAC, every authenticated user would have full access to your cluster—a significant security risk. RBAC enables you to:

• Limit access to only what’s necessary for each role
• Prevent accidental changes by restricting who can modify resources
• Meet compliance requirements by maintaining an audit trail of permissions
• Isolate workloads by giving applications minimal permissions

Practical Example

Here’s a simple example: allowing a developer to view pods in their namespace but not delete them:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

This role defines permissions. To grant it to a user, you create a RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: development
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Best Practices

1. Start with least privilege - Grant only the minimum permissions needed
2. Use namespaces - Isolate permissions by namespace when possible
3. Group users - Use groups instead of individual users for easier management
4. Regular audits - Review permissions periodically to ensure they’re still appropriate
5. Document exceptions - Keep track of why special permissions were granted

Common Patterns

• Read-only access - For developers who need to debug but not modify
• Namespace isolation - Each team gets their own namespace with limited cross-namespace access
• ServiceAccount permissions - Applications run with minimal permissions via ServiceAccounts
• Cluster administration - Separate roles for cluster admins vs namespace admins

Topics

• Roles & Bindings - Deep dive into Roles, ClusterRoles, and their bindings
• Least Privilege - Implementing the principle of least privilege

See Also

• Authentication & Authorization - How users authenticate before RBAC applies
• ServiceAccounts - Using ServiceAccounts with RBAC