Knowing the RBAC primitives is step one. Applying them correctly — least privilege, preventing escalation, managing at scale — is where production security lives. This lesson covers the patterns that experienced K8s operators use.

1. Least Privilege Design

The principle: grant only the minimum permissions needed for the task, nothing more.

Anti-Patterns to Avoid

Least Privilege Checklist

# For each role, ask:
# 1. What SPECIFIC resources does this workload/user need?
#    → List them explicitly (no wildcards)
# 2. What SPECIFIC verbs are needed?
#    → Read-only: get, list, watch
#    → Deploy: get, list, create, update, patch
#    → Full control: all verbs (rare)
# 3. What SCOPE is needed?
#    → Single namespace: Role + RoleBinding
#    → All namespaces: ClusterRole + ClusterRoleBinding (justify this!)
# 4. Can we restrict to SPECIFIC resource names?
#    → resourceNames: ["specific-secret"] (narrow access)

Example: Layered Access for One Team

# Developer — can deploy but not touch infrastructure:
rules:
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
  - apiGroups: [""]
    resources: ["pods", "pods/log", "services", "configmaps"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["services", "configmaps"]
    verbs: ["create", "update", "patch"]
# NO: secrets, pods/exec, RBAC roles, nodes, PVs

# On-call engineer — read everything + exec for debugging:
rules:
  - apiGroups: ["", "apps", "batch"]
    resources: ["*"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods/exec", "pods/log"]
    verbs: ["create", "get"]
# NO: create/delete (read + debug only)

# Platform admin — full namespace control (but not cluster-wide):
# → Use built-in ClusterRole "admin" with RoleBinding per namespace

2. Aggregated ClusterRoles

Aggregation lets you compose ClusterRoles from smaller pieces using label selectors. When a new CRD is installed, it can add permissions to existing roles without modifying them.

How It Works

# Base ClusterRole with aggregation rule:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-view
  labels:
    rbac.example.com/aggregate-to-monitoring: "true"  # ← contributes rules
rules:
  - apiGroups: ["monitoring.coreos.com"]
    resources: ["prometheuses", "alertmanagers"]
    verbs: ["get", "list", "watch"]
---
# Aggregating ClusterRole (collects rules from labeled roles):
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aggregate-monitoring
aggregationRule:
  clusterRoleSelectors:
    - matchLabels:
        rbac.example.com/aggregate-to-monitoring: "true"
rules: []   # ← auto-populated from matched ClusterRoles!

Built-in Aggregation (How K8s Does It)

The built-in admin, edit, and view ClusterRoles use aggregation:

# The "edit" ClusterRole aggregates all roles labeled:
#   rbac.authorization.k8s.io/aggregate-to-edit: "true"

# When you install a CRD (e.g., cert-manager), it adds:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cert-manager-edit
  labels:
    rbac.authorization.k8s.io/aggregate-to-edit: "true"    # ← auto-added to "edit"
    rbac.authorization.k8s.io/aggregate-to-admin: "true"   # ← auto-added to "admin"
rules:
  - apiGroups: ["cert-manager.io"]
    resources: ["certificates", "issuers"]
    verbs: ["create", "delete", "get", "list", "patch", "update"]

# Now anyone with "edit" role automatically gets cert-manager permissions!
# No need to update existing RoleBindings.

3. Escalation Prevention

Kubernetes prevents privilege escalation: you cannot grant permissions you don't already have.

The Escalation Check

# If user "jane" has only "get pods" permission:
# She CANNOT create a RoleBinding that grants "delete pods"
# → API server rejects: "user jane cannot grant verb 'delete' on resource 'pods'"

# To create/update Roles and Bindings, you must ALREADY have:
# 1. Permission to create/update roles/rolebindings (meta-permission)
# 2. ALL the permissions contained in the role you're creating (escalation check)

# Exception: the "escalate" verb bypasses this check:
rules:
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources: ["roles", "clusterroles"]
    verbs: ["escalate"]     # ← Allows creating roles with more perms than you have
# EXTREMELY DANGEROUS — equivalent to cluster-admin

The "bind" Verb

# The "bind" verb allows creating bindings to ANY role:
rules:
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources: ["rolebindings", "clusterrolebindings"]
    verbs: ["create"]       # Can create bindings...
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources: ["roles", "clusterroles"]
    verbs: ["bind"]         # ...to any role (bypasses escalation check)
# ALSO DANGEROUS — can bind cluster-admin to themselves

4. Dangerous Permission Combinations

5. Auditing & Debugging RBAC

# Who has access to what?
kubectl auth can-i --list --as=jane -n production

# Can this SA create deployments?
kubectl auth can-i create deployments \
  --as=system:serviceaccount:ci:deployer -n production

# Find all RoleBindings in a namespace:
kubectl get rolebindings -n production -o wide
# NAME        ROLE                    SUBJECTS
# dev-edit    ClusterRole/edit        User/jane, Group/developers

# Find all ClusterRoleBindings for a specific user:
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.subjects[]? | .name=="jane") | .metadata.name'

# What permissions does a ClusterRole grant?
kubectl describe clusterrole edit

# Audit: find overly permissive bindings (cluster-admin):
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | 
      {name: .metadata.name, subjects: .subjects}'

Tools for RBAC Analysis

Summary

kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects[]'