Kubernetes RBAC: From Cluster-Admin Sprawl to Least Privilege

The Cluster-Admin Problem

I audit Kubernetes environments regularly. The most common finding: developers and CI/CD service accounts with cluster-admin. It happens because it's easy, and because Kubernetes RBAC is genuinely complex to configure correctly. But cluster-admin is global and irrevocable — compromise one token and you own the cluster.

Auditing Existing Bindings

# Who has cluster-admin?
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name == "cluster-admin") | .subjects'

# What can a service account do?
kubectl auth can-i --list --as=system:serviceaccount:default:myapp

Writing Least-Privilege Roles

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: deployment-manager
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "update", "patch"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

CI/CD Minimal Permissions

Your CI pipeline should only be able to update the image tag in specific deployments. Not create secrets, not read config maps from other namespaces.

Rakkess for Visual Audit

kubectl krew install rakkess
kubectl rakkess --sa cicd:cicd-runner

Defensive Takeaways

• Remove all cluster-admin bindings that aren't break-glass accounts
• Service accounts should have namespace-scoped roles, not cluster roles
• Rotate service account tokens — use projected volumes with bounded TTLs
• Run kube-bench to validate CIS Kubernetes benchmark compliance