Looking at a Role or ClusterRole tells you which verbs and resources are granted. What it often doesn’t tell you is what those permissions actually mean from a security perspective.A permission that looks relatively harmless in isolation can become a privilege escalation path when combined with another permission.
Some paths depend on the namespace, admission configuration, cloud provider, or other properties of the cluster. And the information needed to understand those paths is often scattered across documentation, CVEs, security research, and implementation details. I built Kubetier to try and make that easier to reason about.
Kubetier maps Kubernetes RBAC permissions to security risk tiers based on the worst realistic security boundary they can break, and documents the privilege escalation paths behind those assessments. A significant part of the work has been researching, testing, and validating those paths rather than simply classifying permissions based on whether they look dangerous.The goal is simple: when reviewing an RBAC grant, make it easier to answer the question: “What am I actually granting here?”
A BIG thanks to everyone that's provided feedback along the way, especially Stian Frøystein for suggesting implementing llms.txt, making the reference easier for LLMs to ingest and use when reasoning about Kubernetes RBAC.This is very much something I want to keep improving, so if you find something that looks wrong, a path I’ve missed, an edge case worth testing, or simply have an idea for making the reference better, I’d love to hear it!Feedback, criticism, corrections and ideas are all very welcome.P.S. There’s also an Easter egg hidden somewhere in the site that unlocks Synthwave Mode. Consider it a tiny CTF. Start by looking for the flag. 🚩