Kubernetes RBAC Risk Calculator

Score Kubernetes RBAC risk from cluster-admin bindings, wildcard verbs and resources, escalate and bind rights and privileged service accounts.

Inputs

ClusterRoleBindings in the clusterbindings

Subjects bound to cluster-adminbindings

Roles granting verbs: ["*"]roles

Roles granting resources: ["*"]roles

Roles granting escalate or bindroles

Roles that can read secrets cluster-wideroles

Service accounts in the clusteraccounts

Service accounts bound to a ClusterRoleaccounts

Namespaces in the clusternamespaces

RBAC Risk Score

77.5/ 100

Risk Level

High

Weighted Risk Points

279points

Risk Points per 100 Bindings

155.0

Cluster-Admin Binding Ratio

5.00%

Wildcard Role Ratio

13.9%

Service Accounts With Cluster Scope

9.05%

Bindings per Namespace

2.81

Highest-Value Fix

Cut the cluster-admin bindings to a break-glass group and audit its use

Step by step

Values used
ClusterRoleBindings in the cluster = 180 bindings; Subjects bound to cluster-admin = 9 bindings; Roles granting verbs: ["*"] = 14 roles; Roles granting resources: ["*"] = 11 roles; Roles granting escalate or bind = 4 roles; Roles that can read secrets cluster-wide = 23 roles; Service accounts in the cluster = 420 accounts; Service accounts bound to a ClusterRole = 38 accounts; Namespaces in the cluster = 64 namespaces
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.
RBAC Risk Score
= 77.5 / 100
Risk Level
= High
Weighted Risk Points
= 279 points
Risk Points per 100 Bindings
= 155.0
Cluster-Admin Binding Ratio
= 5.00
Wildcard Role Ratio
= 13.9

How it works

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.

Formulas

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.

riskPoints: Weighted total of dangerous grants
clusterAdminBindings: Subjects bound directly to the cluster-admin ClusterRole
escalateBindRoles: Roles granting the escalate or bind verb

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.

pointsPer100Bindings: Risk points ÷ ClusterRoleBindings × 100
riskScore: 0–100 normalised RBAC risk

Frequently Asked Questions

How is Kubernetes RBAC Risk calculated?

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.

Why does Kubernetes RBAC Risk matter?

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.

What values do I need to enter?

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.

Why is reading secrets treated as privilege escalation?

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.

Are ClusterRoles always worse than Roles?

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.

You might also need

Pod Security Risk Calculator Admission Controller Coverage Calculator Container Escape Risk Calculator