RBAC and Access Control

Kubernetes clusters host diverse workloads and multiple engineering teams. Without access boundaries, any developer or compromised container could inspect secrets, delete databases, or compromise worker nodes.

Role-Based Access Control (RBAC) is the gatekeeper of the Kubernetes API Server. It ensures that every user and workload can only perform explicitly permitted operations on designated resources.

The Authentication vs. Authorization Pipeline

When an API request hits kube-apiserver, it passes through three sequential gates:

1. Authentication (Who are you?): Validates client certificates, bearer tokens, or OIDC tokens (e.g., Google Workspace, Okta).
2. Authorization (What can you do?): Evaluates RBAC rules matching the identity.
3. Admission Control (Is this request safe?): Validates and mutates the resource before persisting to etcd.

---

Core RBAC Objects: The 4 Primitives

Kubernetes divides RBAC into permissions (Roles) and assignments (RoleBindings), further separated by scope:

Scope	Permission Definition	Assignment to Identity
Namespace-scoped	Role	RoleBinding
Cluster-wide	ClusterRole	ClusterRoleBinding

1. Role (Namespace-Specific)

Defines what actions (verbs) can be taken on which resources inside a specific namespace.

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

2. RoleBinding

Connects a Role to a user, group, or ServiceAccount:

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

3. ClusterRole & ClusterRoleBinding

Used for non-namespaced resources (like Nodes, PersistentVolumes, Namespaces) or when granting permissions across all namespaces in the cluster (e.g. cluster-wide monitoring systems like Prometheus).

---

ServiceAccounts: Identities for Pods

Humans use usernames or OIDC tokens; Pods use ServiceAccounts.

By default, every namespace has a default ServiceAccount. If your pod doesn't need to communicate with the Kubernetes API, you should disable automatic token mounting to prevent credential theft if the container is compromised:

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  automountServiceAccountToken: false
  containers:
    - name: web
      image: nginx

---

Common RBAC Pitfalls

• Binding cluster-admin carelessly: Giving broad cluster-admin to CI/CD pipelines or developers destroys blast radius isolation.
• Granting wildcard verbs (*): Rules with verbs: ["*"] or resources: ["*"] create hidden escalation paths (e.g., ability to create pods can be used to mount host filesystems and escape to the node).
• Overlooking impersonate permissions: The impersonate verb lets an entity act as another user or group, effectively bypassing access controls.