How does RBAC work and how do you debug a permission denied error

Crisp answer: RBAC (Role-Based Access Control) uses Roles (or ClusterRoles) to define allowed actions, and RoleBindings (or ClusterRoleBindings) to assign them to subjects (users, service accounts, groups). A permission denied means no Role grants the action on that resource.

The four RBAC objects:

A minimal Role example:

# Allow reading pods in the staging namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: staging
rules:
- apiGroups: [""]           # core API group (pods, services, etc.)
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: staging
subjects:
- kind: ServiceAccount
  name: monitoring-agent
  namespace: staging
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Verbs:

get, list, watch, create, update, patch, delete, deletecollection

Debugging permission denied:

# Test if an action is allowed:
kubectl auth can-i get pods --as=system:serviceaccount:staging:monitoring-agent -n staging
# yes or no

kubectl auth can-i "*" "*" --as=system:serviceaccount:kube-system:default
# Check if a service account has broad permissions (security audit)

# See all roles and bindings in a namespace:
kubectl get roles,rolebindings -n staging
kubectl describe rolebinding read-pods -n staging

# Which ClusterRoles exist?
kubectl get clusterroles | grep -v "system:"

# Check if a user/SA has a specific permission:
kubectl auth can-i create deployments --as=alice -n production
# no

# Verbose API server response for an actual denied request:
kubectl get pods -v 8 --as=alice -n production 2>&1 | grep "Response Status"
# Response Status: 403 Forbidden

Service account tokens:

Every pod runs as a service account. The default service account has minimal permissions. If your application pod needs to talk to the Kubernetes API (common for operators and monitoring agents), create a dedicated service account with exactly the permissions it needs:

# See what SA a pod is using:
kubectl describe pod <pod> | grep "Service Account"

# See the token mounted in the pod:
kubectl exec <pod> -- cat /var/run/secrets/kubernetes.io/serviceaccount/token

What to say in the interview:

"RBAC has four objects: Role and ClusterRole define what actions are allowed, RoleBinding and ClusterRoleBinding assign them to subjects. The key debugging tool is kubectl auth can-i — I can test whether a specific user or service account can do something before I even look at the YAML. A common issue is a pod that needs to call the API server for autodiscovery, but the default service account has no permissions. Fix: create a minimal Role with exactly the resources and verbs needed, bind it to a dedicated service account, and reference that SA in the pod spec."