RBAC and least privilege

RBAC and least privilege

graph LR S["Subject<br/>User / Group / ServiceAccount"] --> B[RoleBinding] B --> R["Role<br/>verbs on resources"] R -.valid in.-> NS[one namespace] S2[Subject] --> CB[ClusterRoleBinding] CB --> CR[ClusterRole] CR -.valid in.-> ALL[whole cluster]
ObjectScopeContains
Rolenamespacerules
ClusterRoleclusterrules (also for nodes, PVs, non-resource URLs)
RoleBindingnamespacesubjects -> Role or ClusterRole (limited to this namespace)
ClusterRoleBindingclustersubjects -> ClusterRole everywhere

Binding a ClusterRole with a RoleBinding is the common pattern: define “developer” once, grant it per namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { name: pod-reader, namespace: dev }
rules:
  - apiGroups: [""]                  # core group
    resources: ["pods", "pods/log"]  # subresource = separate permission
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: { name: jane-reads-pods, namespace: dev }
subjects:
  - kind: User
    name: jane
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
kubectl create role pod-reader --verb=get,list,watch --resource=pods,pods/log -n dev
kubectl create rolebinding jane-reads-pods --role=pod-reader --user=jane -n dev
kubectl create rolebinding devs-edit --clusterrole=edit --group=dev-team -n dev

Built-in ClusterRoles: view, edit, admin, cluster-admin.

Least privilege - the dangerous permissions

PermissionWhy it is powerful
get/list secretsreads every password and token in the namespace
create podscan run a Pod with any ServiceAccount of the namespace
pods/execshell into running apps and their secrets
bind, escalate, impersonategrant yourself more
nodes/proxy, create on privileged Podsreach the node
* on *cluster-admin by another name

Rules of thumb: bind to groups, not people; prefer namespaced Roles; no wildcards; review with kubectl auth can-i --list --as.

References