Kubernetes RBAC

Role-Based Access Control (RBAC) is the modern standard for Kubernetes authorization. It replaces legacy ABAC with four declarative API objects — Role, ClusterRole, RoleBinding, and ClusterRoleBinding — that grant fine-grained permissions to users, groups, and ServiceAccounts. Source: CKA Day 22 Source: CKA Day 23

The Four RBAC Objects

Object	Scope	Purpose
Role	Namespace	Defines a set of permissions (rules) within a single Namespace
ClusterRole	Cluster-wide	Defines a set of permissions across all Namespaces or on cluster-scoped resources
RoleBinding	Namespace	Binds a Role (or ClusterRole) to subjects within a single Namespace
ClusterRoleBinding	Cluster-wide	Binds a ClusterRole to subjects across the entire cluster

A critical distinction: ClusterRoles can be bound with RoleBindings to grant cluster-level permissions inside a single Namespace. However, Roles cannot be bound with ClusterRoleBindings — a ClusterRoleBinding requires a ClusterRole.

YAML Anatomy

Role

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

ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]

RoleBinding

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

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: devops
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Important: roleRef is immutable after creation. To change the bound Role, you must delete and recreate the Binding. Source: CKA Day 22

Rules: Verbs, Resources, and apiGroups

Each rule is a triple of (apiGroups, resources, verbs):

Field	Description	Examples
apiGroups	The API group of the resource	"" for core, "apps" for Deployments, "networking.k8s.io" for Ingress
resources	The plural resource name	pods, services, deployments, secrets, configmaps
verbs	The allowed actions	get, list, watch, create, update, patch, delete, deletecollection
resourceNames	Optional: restrict to specific named instances	["my-pod", "my-secret"]

API Groups: Core vs Named — Every Kubernetes resource belongs to an API group. The “core” group (e.g., v1 for Pods, Services, ConfigMaps) has no group suffix and is referenced in RBAC rules as "" (empty string). Named groups include apps (Deployments, ReplicaSets), rbac.authorization.k8s.io (Roles, Bindings), networking.k8s.io (Ingress, NetworkPolicies), and batch (Jobs, CronJobs). When writing a Role, always specify the correct apiGroups field — a blank value targets only core resources, not Deployments or other named-group objects. Source: CKA Day 23

Wildcard caution: verbs: ["*"] and resources: ["*"] grant broad permissions. In production, enumerate exact verbs and resources.

Subjects: Who Gets Access

A subject can be one of three kinds:

Kind	Example	Use Case
User	name: alice	Human operators authenticated via client certs or OIDC
Group	name: developers	OIDC groups or certificate Organization fields
ServiceAccount	name: prometheus, namespace: monitoring	In-cluster workloads that call the API server

ServiceAccount namespace trap: When binding a ServiceAccount, you must specify its Namespace in the subjects block, even if the Binding is in the same Namespace. Source: CKA Day 22

Built-in ClusterRoles

Kubernetes ships with several default ClusterRoles:

ClusterRole	Purpose
cluster-admin	Full control over every resource in the cluster
admin	Full control within a Namespace, including RBAC management
edit	Read/write access to most namespace resources (cannot manage RBAC)
view	Read-only access to most namespace resources

These are designed to be bound with RoleBindings for namespace-level delegation or ClusterRoleBindings for cluster-wide access.

Namespace-Scoped vs Cluster-Scoped Resources

Scope	Examples	RBAC Object
Namespace-scoped	Pods, Services, ConfigMaps, Secrets, Deployments	Role + RoleBinding
Cluster-scoped	Nodes, PersistentVolumes, ClusterRoles, Namespaces themselves	ClusterRole + ClusterRoleBinding

A common CKA exam pattern: granting a user the ability to create Namespaces requires a ClusterRole with create on namespaces, bound via ClusterRoleBinding. Source: CKA Day 22

Imperative RBAC Generation

For exam speed, generate roles and bindings without hand-editing YAML:

# Create a Role imperatively
kubectl create role pod-reader --verb=get,list,watch --resource=pods --dry-run=client -o yaml
 
# Create a RoleBinding imperatively
kubectl create rolebinding read-pods --role=pod-reader --user=krishna --dry-run=client -o yaml
 
# Bind a ClusterRole to a namespace (common for admin/edit/view delegation)
kubectl create rolebinding dev-edit --clusterrole=edit --user=dev1 --namespace=default --dry-run=client -o yaml

Exam trap: kubectl create rolebinding requires --role for Roles and --clusterrole for ClusterRoles. Mixing them produces an invalid binding. Source: CKA Day 23

Testing and Debugging Permissions

kubectl auth can-i

The fastest way to verify RBAC without switching users is impersonation:

# Check if user "krishna" can get pods
kubectl auth can-i get pods --as krishna --namespace default
 
# Check if user can create deployments (useful after editing a Role)
kubectl auth can-i create deployments --as krishna --namespace default
 
# List all permissions for the current user
kubectl auth can-i --list

Cluster admin advantage: Users with impersonate rights (e.g., cluster-admin) can test any user’s permissions without logging in as them. This is the standard CKA exam debugging pattern. Source: CKA Day 23

Counting RBAC Objects (Exam Task Pattern)

When the exam asks “how many roles exist in the cluster?”, suppress headers and count lines:

kubectl get roles --no-headers --all-namespaces | wc -l
kubectl get rolebindings --no-headers --all-namespaces | wc -l

Inspecting Role and Binding Details

# Describe a Role to see its rules
kubectl describe role pod-reader --namespace default
 
# Describe a RoleBinding to see which subjects are bound
kubectl describe rolebinding read-pods --namespace default
 
# List all bindings referencing a specific role
kubectl get rolebindings -o json | jq '.items[] | select(.roleRef.name=="pod-reader")'

CKA Speed Patterns

• Generate manifest: kubectl create role pod-reader --verb=get,list,watch --resource=pods --dry-run=client -o yaml
• Generate binding: kubectl create rolebinding read-pods --role=pod-reader --user=jane --dry-run=client -o yaml
• Test permissions: kubectl auth can-i create deployments --as jane --namespace default
• List bindings for a role: kubectl get rolebindings -o json | jq '.items[] | select(.roleRef.name=="pod-reader")'

Related Pages

• Kubernetes Authentication & Authorization — the two-gate security model and auth modules
• Kubernetes Kubeconfig — context switching and user identity for RBAC testing
• Kubernetes Namespaces — RBAC scope boundaries and namespace isolation
• Kubernetes Architecture — API server request flow through authn/authz
• Kubernetes ConfigMaps and Secrets — resources that often require restricted RBAC policies
• CKA Certification — exam weighting and RBAC task frequency

---

Tags: kubernetes rbac security authorization cka role clusterrole rolebinding