RBAC (Role-Based Access Control) is the authorization layer that answers: "Can this user/SA do this action on this resource?" It's the most important security mechanism in Kubernetes — every API request passes through RBAC after authentication. Mastering it is essential for CKA, CKS, and production cluster security.

1. The RBAC Model — Four Resources

Combination Rules

2. Roles — Defining Permissions

Role (Namespaced)

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: production
rules:
  - apiGroups: [""]              # Core group (Pods, Services, etc.)
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods/log"]      # Subresource
    verbs: ["get"]

ClusterRole (Cluster-Wide)

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader              # No namespace (cluster-scoped)
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list"]

The Verb Matrix

Rule Building Blocks

# Multiple resources in one rule (AND between apiGroups+resources, OR between verbs):
rules:
  - apiGroups: ["", "apps"]                     # Core AND apps groups
    resources: ["pods", "deployments"]
    verbs: ["get", "list", "create", "delete"]

# Restrict to specific resource names:
  - apiGroups: [""]
    resources: ["secrets"]
    resourceNames: ["db-creds", "api-key"]      # Only these specific secrets
    verbs: ["get"]

# Subresources:
  - apiGroups: [""]
    resources: ["pods/exec"]                     # Pod exec
    verbs: ["create"]                            # exec requires "create" verb
  - apiGroups: ["apps"]
    resources: ["deployments/scale"]             # Scale subresource
    verbs: ["get", "update"]

# Non-resource URLs (health endpoints, metrics):
  - nonResourceURLs: ["/healthz", "/metrics"]
    verbs: ["get"]

3. Bindings — Connecting WHO to WHAT

RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:                           # WHO gets the permissions
  - kind: User
    name: jane
    apiGroup: rbac.authorization.k8s.io
  - kind: Group
    name: developers
    apiGroup: rbac.authorization.k8s.io
  - kind: ServiceAccount
    name: ci-sa
    namespace: ci-cd               # SA namespace (can be different!)
roleRef:                            # WHAT permissions (immutable after creation!)
  kind: Role                        # or ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding      # No namespace (cluster-scoped)
subjects:
  - kind: User
    name: admin@company.com
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin              # Built-in superuser role
  apiGroup: rbac.authorization.k8s.io

Subject Types

# Imperative commands (fast for exams):
kubectl create rolebinding read-pods \
  --role=pod-reader \
  --user=jane \
  --serviceaccount=ci-cd:ci-sa \
  -n production

kubectl create clusterrolebinding admin-binding \
  --clusterrole=cluster-admin \
  --user=admin@company.com

4. Testing RBAC — kubectl auth can-i

# Check your own permissions:
kubectl auth can-i create deployments -n production
# yes

kubectl auth can-i delete nodes
# no

# Check as another user (requires admin):
kubectl auth can-i get secrets -n production --as=jane
# no

kubectl auth can-i get pods -n production --as=system:serviceaccount:ci-cd:ci-sa
# yes

# List ALL permissions for a user:
kubectl auth can-i --list --as=jane -n production
# Resources   Non-Resource URLs   Resource Names   Verbs
# pods        []                  []               [get list watch]
# pods/log    []                  []               [get]

5. Built-in ClusterRoles

# Give a developer full edit access in their namespace:
kubectl create rolebinding dev-edit \
  --clusterrole=edit \
  --user=jane \
  -n team-alpha

# ClusterRole "edit" used with RoleBinding → scoped to namespace team-alpha
# Jane can create/delete Pods, Deployments, Services in team-alpha only

6. Common Patterns

# Pattern: CI/CD pipeline — create/update Deployments only
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployer
  namespace: production
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "create", "update", "patch"]
  - apiGroups: [""]
    resources: ["services"]
    verbs: ["get", "list", "create", "update"]
# NO: delete, pods/exec, secrets — principle of least privilege

# Pattern: Monitoring — read everything, write nothing
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-reader
rules:
  - apiGroups: ["", "apps", "batch"]
    resources: ["*"]
    verbs: ["get", "list", "watch"]     # Read only, across all namespaces
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: []                            # Explicitly NO access to Secrets

Summary

rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get","list","create","update","patch"]
  - apiGroups: [""]
    resources: ["services","configmaps"]
    verbs: ["get","list","create","update"]

- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"]