Lion Cipher Lab

Audit Kubernetes RBAC for risky permissions with rbac-tool

• Cloud Security
• Intermediate
• ~50 min
• Free · no account required

Why it matters

Almost every real Kubernetes breach that starts with a single compromised container ends the same way: the attacker looks at what the pod's ServiceAccount is allowed to do, and walks it. Role-Based Access Control (RBAC) is the mechanism that is supposed to stop that walk — it decides which identities may perform which actions on which resources — and in a cluster of any age it accumulates cruft. Someone grants a controller cluster-wide access to secrets 'just to get it working'; a Helm chart ships a ClusterRole with a wildcard because the author did not want a support ticket; a ServiceAccount…

What you'll learn

• reading RBAC as a security surface: what a Role, ClusterRole, RoleBinding, ClusterRoleBinding and ServiceAccount actually grant, and why the VERB is where the danger lives
• naming the genuinely dangerous verbs and knowing WHY each is dangerous — get/list secrets (credential theft), escalate (grant yourself more than you have), bind (attach a powerful role to yourself), impersonate (act as another identity), the wildcard * (everything), create pods (often node/root via a privileged pod)
• standing up a throwaway local cluster with kind (Kubernetes IN Docker) and applying deliberately over-permissive RBAC so you have a realistic thing to audit — all on your own machine, free and offline
• installing and driving Aqua Security's rbac-tool (as a kubectl krew plugin OR a standalone binary) — the three commands that matter: policy-rules, who-can, and analysis
• answering the two questions an auditor actually asks: 'what can THIS subject do?' (rbac-tool policy-rules) and 'who can do THIS dangerous thing?' (rbac-tool who-can get secrets -A)
• running rbac-tool analysis to get risk-scored findings that flag wildcards, escalate/bind/impersonate, cluster-wide secrets read and exec — instead of eyeballing YAML by hand
• remediating for real and MEASURING it: scope the Role to one namespace and specific resourceNames, drop the wildcard, remove escalate/bind/impersonate — then re-run who-can and analysis and watch the risky subject disappear and the report go clean
• judgment: an over-permissive ServiceAccount is a container-compromise-to-cluster-admin path, and the honest limits of RBAC auditing — it sees DECLARED permissions, not what a pod could reach by other means

Steps in this lab

1. RBAC in one paragraph, and why the VERB is where the danger lives
2. Stand up a throwaway cluster with kind — your machine only
3. Apply the over-permissive RBAC on purpose — the thing you will audit
4. Install rbac-tool (krew plugin OR standalone binary)
5. BEFORE: find the risky permissions — who-can, policy-rules, analysis
6. Why each of those verbs is genuinely dangerous
7. Remediate: scope it down, drop the wildcard, remove the escape verbs
8. AFTER: re-run the same audit and prove the fix
9. Do it better — and the honest limits of RBAC auditing

Open the full interactive lab →