What is the principle of least privilege as applied to Kubernetes RBAC design?

The anti-pattern: broad, convenient permissions

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: way-too-broad
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]     # everything, on everything, cluster-wide

Granting this to a ServiceAccount used by, say, a CI/CD pipeline that only actually needs to deploy Deployments and Services into one specific namespace means that if the CI pipeline's credentials are ever compromised (a leaked token, a supply-chain attack on a pipeline dependency), the attacker gets complete control of the entire cluster — every namespace, every Secret, every Node — vastly beyond what the pipeline ever legitimately needed.

The least-privilege alternative

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: staging
  name: ci-deployer
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "create", "update", "patch"]
  - apiGroups: [""]
    resources: ["services"]
    verbs: ["get", "list", "create", "update", "patch"]

Scoped to exactly the resource types, exactly the verbs, and exactly the namespace the CI pipeline actually needs — a compromise of this specific credential is now bounded to "can mess with Deployments and Services in staging," a vastly smaller blast radius than full cluster-admin.

Practical principles for applying this

• Namespace-scope by default — prefer Role + RoleBinding over ClusterRole + ClusterRoleBinding whenever the need genuinely doesn't span the whole cluster (which is most of the time).
• Enumerate specific resources and verbs, avoid wildcards — resources: ["pods"] and verbs: ["get", "list"] rather than resources: ["*"] and verbs: ["*"], even when it's more tedious to write out.
• Distinct ServiceAccounts per distinct responsibility — don't reuse one broadly-permissioned ServiceAccount across multiple unrelated controllers/pipelines; each should have its own narrowly-scoped identity, so a compromise of one doesn't cascade into unrelated systems' access.
• Regularly audit granted permissions against what's actually used — kubectl auth can-i --list --as=system:serviceaccount:<namespace>:<name> and similar tooling can reveal permissions granted "just in case" long ago that were never actually needed and were never revoked.
• Avoid cluster-admin except for a small number of genuinely trusted humans/processes — this built-in role should be treated as an exceptional, rarely-granted escape hatch, not a convenient default for anyone who occasionally needs broader access.

Why this is worth stating as a deliberate design principle, not just a checklist

The value of articulating least privilege explicitly (rather than just listing RBAC syntax) is recognizing that RBAC's flexibility to grant broad permissions doesn't mean broad permissions are ever the right default — every grant should be justified by an actual, specific need, and the discipline of scoping down to exactly that need (even when a broader grant would technically "just work" with less upfront effort) is what limits real-world damage when — not if — some credential eventually leaks or some component is compromised.