E-KUB
kubectl
The official Kubernetes CLI for querying, and where authorized, controlling cluster resources during an assessment.
OVERVIEW
kubectl is the standard command-line client bundled with every Kubernetes distribution, talking to the API server over the same REST interface any other client uses. On an assessment it's rarely the tool that finds a vulnerability by itself — it's the connective tissue: reading whatever RBAC allows (`kubectl auth can-i`, `get`, `describe`), pivoting into workloads (`exec`, `port-forward`, `cp`), and confirming whether a misconfiguration flagged by a scanner is actually reachable and abusable from the credentials in hand.
Because its behavior is entirely governed by the kubeconfig or service account token it runs with, the same binary doubles as both the enumeration tool for "what can I do with this credential" and the exploitation tool for actually doing it — which is why nearly every other Kubernetes-focused tool in this directory (kubectl-who-can, rakkess, kube-hunter) is either a kubectl plugin or assumes kubectl is already configured against the target.
USE CASES
Practical use cases
- 01
Enumerating namespaces, workloads, secrets, and RBAC bindings reachable with a given credential (`kubectl get`, `describe`, `auth can-i`).
- 02
Testing whether a discovered service account token or kubeconfig actually authenticates, and what it's scoped to.
- 03
Pivoting into a running pod via `exec` or exfiltrating data via `cp`/`port-forward` once access is confirmed.
- 04
Confirming, in the client's own environment, whether a misconfiguration flagged by a scanner (kube-hunter, rbac-police, Trivy) is actually reachable and exploitable.
QUICK START
As the baseline tool for any Kubernetes assessment step — reading what a credential can see, and later, testing what it can do.
- Confirm the kubeconfig or token in hand is inside scope, and note whether it belongs to a human user or a service account.
- Run `kubectl auth can-i --list` to see the full set of permissions before touching anything else.
- Enumerate the namespaces, workloads, and secrets the credential can read, noting anything unexpectedly permissive.
- Where scope allows, test the boundaries found — `exec` into a pod, read a mounted service account token, `port-forward` to an internal service.
kubectl auth can-i --list --as=system:serviceaccount:default:defaultBEFORE YOU RUN IT
What to check before running it
Every command runs with the full authority of whatever credential is loaded in KUBECONFIG — double-check the active context before running anything destructive, especially `delete`, `edit`, `exec`, or `apply` against a client's cluster.
`kubectl auth can-i` only evaluates RBAC; a namespace or resource can be RBAC-permitted yet still blocked by an admission controller (OPA/Gatekeeper, Kyverno, Pod Security Admission) — verify actual access rather than inferring it from the RBAC result alone.
Command history, shell aliases, and the tester's own `~/.kube/config` can leak cluster endpoints and credentials — treat the operator's workstation as in-scope for OPSEC during the engagement.