E-KUB
kubectl-who-can
kubectl plugin that lists every user, group, or service account with RBAC permission to run a given verb on a resource.
OVERVIEW
kubectl-who-can (aquasecurity/kubectl-who-can) answers a question RBAC's own tooling doesn't answer directly: given a verb and a resource — "who can create pods" or "who can get secrets in namespace prod" — it walks every ClusterRoleBinding and RoleBinding in the cluster and reports which users, groups, and service accounts are granted that permission, directly or through a role.
That reverse lookup turns a privilege-escalation hunt from reading every RoleBinding by hand into a single command, which is why it's usually run right after gaining any authenticated foothold in a cluster: it surfaces over-permissioned service accounts and roles that grant far more than the workload attached to them needs.
USE CASES
Practical use cases
- 01
Answering "who can do X to Y" directly instead of manually cross-referencing Roles and RoleBindings.
- 02
Finding service accounts granted cluster-admin-equivalent verbs (create pods, bind, escalate) far beyond what their workload needs.
- 03
Scoping a privilege-escalation path: once a service account token is compromised, checking exactly what else it — or any other identity sharing its bindings — can reach.
- 04
Auditing a namespace's RBAC before a release to confirm the bindings actually match the least-privilege design that was intended.
QUICK START
Right after gaining any authenticated foothold, to reverse-lookup which identities hold a specific dangerous RBAC grant.
- Confirm kubectl is configured against the in-scope cluster with a credential permitted to read RBAC objects.
- Install the plugin via krew (`kubectl krew install who-can`) or download a release binary.
- Run it against a specific verb/resource pair, optionally scoped to a namespace with `-n`.
- Cross-reference any surprising subject against its actual workload to judge whether the grant is justified.
kubectl who-can create pods --namespace defaultBEFORE YOU RUN IT
What to check before running it
It reports what RBAC grants, not what is actually exploitable — a wide grant on an unused legacy service account is a lower-priority finding than the same grant on a token mounted into an internet-facing pod.
Running it requires enough RBAC access itself to list ClusterRoles, Roles, and their bindings; a low-privilege credential may not be able to complete a full audit, which is itself worth noting.
It only covers native Kubernetes RBAC — cluster-specific authorization layers (cloud IAM bound to nodes, OPA/Gatekeeper policies) aren't reflected in its output.