Score Kubernetes RBAC risk from cluster-admin bindings, wildcard verbs and resources, escalate and bind rights and privileged service accounts.
The weights follow how quickly each grant reaches full cluster control. Cluster-admin is the endpoint, so it is 10 points; escalate and bind are 8 because they are cluster-admin one API call later; wildcard resources beat wildcard verbs because a wildcard verb on pods is far narrower than any verb on everything. Cluster-wide secret read is scored because it usually yields a token that is cluster-admin anyway. Kubernetes RBAC has no built-in review, bindings accumulate silently through Helm charts and operators, and the shortest path to owning a cluster is almost always a service account somebody bound to a ClusterRole for convenience in 2021.
Kubernetes RBAC Risk
Risk points = 10 × cluster-admin bindings + 8 × escalate/bind roles + 5 × wildcard-resource roles + 4 × wildcard-verb roles + 2 × cluster-wide secret readers.
Density normalisation
Risk score = 0.5 × risk points per 100 ClusterRoleBindings, clamped to 0–100 — a density measure so large clusters are not penalised for size alone.
Risk points = 10 × cluster-admin bindings + 8 × escalate/bind roles + 5 × wildcard-resource roles + 4 × wildcard-verb roles + 2 × cluster-wide secret readers. The weights follow how quickly each grant reaches full cluster control. Cluster-admin is the endpoint, so it is 10 points; escalate and bind are 8 because they are cluster-admin one API call later; wildcard resources beat wildcard verbs because a wildcard verb on pods is far narrower than any verb on everything. Cluster-wide secret read is scored because it usually yields a token that is cluster-admin anyway.
Kubernetes RBAC has no built-in review, bindings accumulate silently through Helm charts and operators, and the shortest path to owning a cluster is almost always a service account somebody bound to a ClusterRole for convenience in 2021.
This calculator takes 9 inputs: ClusterRoleBindings in the cluster, Subjects bound to cluster-admin, Roles granting verbs: ["*"], Roles granting resources: ["*"], Roles granting escalate or bind, Roles that can read secrets cluster-wide, Service accounts in the cluster, Service accounts bound to a ClusterRole, Namespaces in the cluster. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Because secrets contain service account tokens, cloud credentials and registry keys. A subject that can read secrets in all namespaces can find a token belonging to a more privileged service account and use it, so cluster-wide secret read is effectively cluster-admin with an extra step.
They are always broader — a ClusterRoleBinding applies the permission in every namespace, including ones created next year. Prefer a Role plus RoleBinding per namespace even when the permission list is identical, because the scope of a Role cannot silently grow.