Grant least privilege with Kubernetes RBAC

The fix

# A Role scoped to one namespace and specific verbs — not ClusterRole, not *
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: orders
  name: orders-app
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch"]

Why it matters

cluster-admin is unrestricted control of the entire cluster: every namespace, every secret, every workload, and the ability to grant others the same. It is the Kubernetes equivalent of root, and it is bound far more widely than it should be — to CI pipelines, to every engineer’s kubeconfig, to operators and controllers that need a fraction of it.

Every over-broad binding is a blast radius. A leaked CI token bound to cluster-admin is the whole cluster. A compromised pod whose service account can get secrets cluster-wide reads every credential you have. RBAC is where you decide that a leak is bounded to one namespace and one verb instead of everything.

The escalation verbs

Three RBAC privileges are special because they let a subject grant themselves more — they’re how limited access becomes cluster-admin:

• escalate on roles — create a role with more permissions than you have.
• bind on rolebindings — bind yourself to a more powerful role.
• impersonate — act as another user or service account, including admins.

A role that grants create/update on roles and rolebindings, or any of the verbs above, is effectively cluster-admin even if it looks scoped. Also watch: create pods is close to node-level power, because a pod can mount host paths and service account tokens (see privileged containers), and access to secrets is access to whatever those secrets protect.

Role, not ClusterRole; verbs, not wildcards

Two habits do most of the work:

• Role (namespaced), not ClusterRole, unless the thing genuinely operates cluster-wide. A ClusterRole bound with a ClusterRoleBinding applies in every namespace — the most common way “just for this app” becomes cluster-wide.
• Named verbs and resources, never *. verbs: ["*"] or resources: ["*"] grants everything including future resources you’ve never heard of. List what the workload calls.

Applications almost never need to write cluster-scoped objects. If a manifest asks for a ClusterRole with wildcards, that’s the finding.

Verify it worked

Find who has cluster-admin — the list should be short and human:

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

Any ServiceAccount or CI identity here is a finding.

Find wildcard permissions across all roles:

kubectl get clusterroles,roles -A -o json | \
  jq -r '.items[] | select(.rules[]?.verbs[]?=="*" or .rules[]?.resources[]?=="*") | "\(.kind)/\(.metadata.name)"' | sort -u

Find the escalation verbs specifically:

kubectl get clusterroles,roles -A -o json | \
  jq -r '.items[] | select(.rules[]?.verbs[]? | . == "escalate" or . == "bind" or . == "impersonate") | .metadata.name' | sort -u

Then check what a specific subject can actually do — this is the resolved answer:

kubectl auth can-i --list --as=system:serviceaccount:orders:orders-app
kubectl auth can-i get secrets --all-namespaces --as=system:serviceaccount:orders:orders-app

no to cluster-wide secrets is what you want from an app service account.

Before you apply this

Tightening RBAC breaks the workload at its next API call — a controller that can’t list the resource it reconciles, a CI job that can’t create a deployment — and the failure is a Forbidden from the API server, often buried in a controller’s logs rather than surfaced.

Find out what a subject actually uses before you cut. The API audit log records it if enabled; without it, kubectl auth can-i --list shows current grants but not usage, so lean on staging:

1. Create the scoped Role and RoleBinding alongside the broad one.
2. Point the workload’s service account at the scoped role.
3. Run it — in staging if you can — and watch for Forbidden errors.
4. Add the specific permissions those errors name. Repeat until clean.
5. Remove the broad binding.

The operators and controllers are the trap. Ingress controllers, cert-manager, service meshes and CI tools often ship with a cluster-admin binding “to keep setup simple,” and narrowing them means reading their docs for the actual permission set. That’s real work, but a compromised ingress controller with cluster-admin is the whole cluster — these are exactly the ones worth scoping.

Don’t lock yourself out. Removing your own cluster-admin binding without another admin path configured means you can’t undo it. Keep a break-glass admin credential (a separate kubeconfig, stored securely) before tightening human access — the API server page covers the client-cert admin that survives an RBAC mistake.

Related

• Disable service account automount — the token RBAC governs.
• Secure the API server — RBAC is only enforced if the authorizer is on.
• Encrypt secrets at rest — what get secrets exposes.