E-CAN
can-they.sh
Bash helper from Bishop Fox's badPods that batch-runs kubectl auth can-i to map what a pod's service account can actually do.
OVERVIEW
can-they.sh, a bash helper script inside Bishop Fox's badPods repository (github.com/BishopFox/badPods/blob/main/scripts/can-they.sh, MIT licensed) rather than a standalone project of its own, automates the manual, repetitive part of Kubernetes RBAC enumeration after landing in a pod: it locates the service account token(s) mounted on the node (or in the current pod), then batch-runs kubectl auth can-i checks against them for the verbs and resources an assessor cares about, instead of retyping the command by hand for every permission.
It supports two modes matching badPods' own training scenarios — run from inside a pod that has the host filesystem mounted (useful after an everything-allowed or hostPath escape), or run from outside against a named pod via kubectl exec — which makes it a natural companion to badPods' vulnerable pod manifests when practicing or demonstrating what an over-permissioned service account actually exposes.
USE CASES
Practical use cases
- 01
Batch-checking a compromised pod's mounted service account token against a list of verbs/resources instead of running kubectl auth can-i by hand each time.
- 02
Enumerating every token found on a node's filesystem after an everything-allowed or hostPath pod escape, to see which one has the most cluster reach.
- 03
Confirming whether an over-permissioned service account can create pods, read secrets, or create clusterrolebindings — common paths to full cluster compromise.
- 04
Pairing with badPods' vulnerable pod manifests to demonstrate RBAC over-permission findings in a training or client-facing lab.
QUICK START
Once inside a Kubernetes pod (or with its mounted token extracted), to systematically enumerate exactly what that pod's service account is authorized to do across the cluster.
- Confirm cluster access and RBAC enumeration from this pod/token are within the authorized scope.
- Download can-they.sh from the badPods repository onto the tester's machine or copy it into the target pod.
- From inside a pod with the host filesystem mounted, run it directly to enumerate every token found on the node.
- From outside, run it against a named pod/namespace via kubectl exec, passing the auth can-i arguments to check.
- Record which verbs/resources each service account can reach, and flag any that enables privilege escalation or lateral movement.
./can-they.sh "-i --list -n kube-system"BEFORE YOU RUN IT
What to check before running it
It is a thin wrapper around kubectl auth can-i, which only reports what RBAC declares — always confirm a promising permission actually works end to end (e.g. successfully reading a secret) before reporting it as exploitable.
Enumerating and using another pod's service account token is credential access against a live cluster; confirm the namespaces and nodes in scope with the client before running it beyond the lab pods badPods ships for practice.
Any token extracted during enumeration is a live credential for the cluster — handle it as sensitive engagement data and avoid leaving copies on the tester's or a shared host's filesystem.