Kubernetes RBAC least privilege: from admin to scoped roles

Replace blanket cluster-admin with namespaced Roles, audit who can do what, and test access with kubectl auth can-i.

Clusters accumulate cluster-admin bindings the way a garage accumulates boxes: a CI account that needed to create a namespace once, a dashboard from a tutorial, an on-call group that was going to be narrowed later. Least privilege does not mean zero cluster-admin bindings, since someone needs break-glass access; it means every binding is intentional, scoped to what its subject does, and provable with kubectl auth can-i. Getting there is a loop, and the first pass through it is the audit above.

See the cluster through the subject’s eyes

kubectl auth can-i --list with --as prints every verb and resource a subject is allowed, resolved through all of its bindings. It is the view to take before writing any Role, because it shows the gap between what the subject is granted and what its workload actually calls. A in the verbs column is a full grant on that resource; a on both columns is cluster-admin under another name. Every authenticated subject also carries a handful of discovery rules (selfsubjectaccessreviews, the /api and /healthz non-resource URLs), which is why a service account with no bindings at all still lists something. kubectl auth whoami shows what the current credentials resolve to, which matters when the surprise is which identity a pipeline is using.

Namespaced Role, bound to one subject

A Role exists in one namespace; a ClusterRole applies everywhere it is bound. Default to a Role unless the subject needs cluster-scoped resources such as Nodes, PersistentVolumes or CustomResourceDefinitions. The verbs come from what the workload does, not from what might be convenient: a deployer needs create, patch and get on Deployments in its namespace, and does not need delete on Secrets to do that. Write the verbs out; a wildcard is a decision not to decide.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: shop
  name: deployer
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "patch", "create"]
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "create", "patch"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]           # to watch a rollout; not delete, not exec
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: shop
  name: jenkins-deploys-shop
subjects:
  - kind: ServiceAccount
    name: jenkins
    namespace: ci
roleRef:
  kind: Role
  name: deployer
  apiGroup: rbac.authorization.k8s.io

A subject that deploys to five namespaces gets five RoleBindings to the same Role definition (or one ClusterRole bound into each namespace with a RoleBinding, which keeps the rules in one place while the grant stays namespaced). What it does not get is a ClusterRoleBinding, because that would make the same verbs valid in kube-system.

The verbs that are more than they look

Grants that quietly equal more than the resource they name

The built-in view, edit and admin ClusterRoles are aggregated: any ClusterRole labelled for aggregation, including ones an operator installs, is folded into them. That makes them reasonable for people working in a namespace and wrong for a controller, whose permission set should not change because someone installed a CRD.

Tokens that are never used should not exist

Every pod gets its service account's token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token unless told otherwise, and most application pods never call the API. A compromised pod with a mounted token and a permissive binding is the standard path from RCE to cluster. automountServiceAccountToken: false on the ServiceAccount (or the Pod) removes the token from pods that do not need it; the ones that do get bound, time-limited tokens by default on current versions, which expire and are tied to the pod that received them.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: web
  namespace: shop
automountServiceAccountToken: false   # the web pods never call the API server

Prove the negative, then keep proving it

The check that matters is the one that should fail. After tightening, ask can-i for the dangerous verbs, not the granted ones, and put the same questions into CI so a later binding cannot quietly widen the account. The audit log is the other half: a create on a ClusterRoleBinding to cluster-admin is the event that undoes this work, and it should page someone.

When a binding is wrong: recovery in order of preference

RBAC decides what a subject may ask the API server. It does not decide what a pod may connect to (NetworkPolicy) or what it may do on the node (Pod Security). The three are usually tightened in that order, and the audit loop here is the one that gets repeated most often, because bindings are what people add under pressure.

Related posts

Quick reference