kubetier
Every Kubernetes RBAC permission ranked T0 to T3 by the security boundary it can break, with the documented privilege-escalation paths that get there.
Consequences by Tier
T0 is game over. Cluster-admin can mean every Secret in every namespace, code on any node, or RBAC rewritten to keep the access. Revoking the grant and rebuilding a compromised worker node deals with the node. It does nothing about credentials that were already read, which stay valid until each one is rotated, or about the cluster CA, which can issue working client certificates until it is rotated itself.
T1 is one step from T0. Whether it gets there depends on the cluster: PodSecurity settings, whether a privileged ServiceAccount sits in the same namespace, whether control-plane nodes accept workloads. Assume it does, since those conditions are common. Even where the escalation stalls, T1 reads every Secret in the namespace, or runs code in an existing pod and uses that pod's ServiceAccount token.
T2 does real damage without reaching cluster-admin. A PodDisruptionBudget can make a drain fail, a toleration can get around node quarantine, and a poisoned workload template can run on the next scale-up. Volumes outlive the namespace that owned them, traffic gets redirected away from a Service, pods in another namespace get evicted. Escalation from here needs preconditions most clusters do not have, so the blast radius stays namespaced or depends on a specific add-on being installed.
T3 is what an attacker reads first. Enumeration tells them which ServiceAccounts are privileged and where to aim the next request. The reads break nothing by themselves, and they save an attacker the work of guessing where to try.
Tiers below T0 come with conditions. Where a T1 or T2 grant does reach cluster-admin alongside the right other grants, the entry carries a Contextual upgrade to T0, so check it against the rest of the role before you treat the tier as the whole answer.
Threat Paths
A tier covers one grant on its own. A threat path chains several of them into a route from an initial foothold to cluster admin, namespace admin, or a cloud account.
RBAC steps are the ones a grant authorises. Each links to the permission it consumes and to the escalation path documenting it. These are also the only steps a Role edit can close.
Runtime steps run inside a container or on a node. No grant authorises them, and the API server never sees them, so an RBAC review of the role comes up empty. They get stopped at admission by pod security and image provenance, or caught in progress by runtime detection.
External steps happen outside the Kubernetes API. An application is tricked into making a request on an attacker's behalf, a token already in hand calls a cloud API, a build pipeline is compromised before the image reaches the cluster. Nothing in a Role or ClusterRole covers any of it. Closing them is work outside RBAC: NetworkPolicy on egress, cloud IAM on the identity the token belongs to, pipeline access control.