Skip to content
ENExplore Calculators

Kubernetes RBAC Risk Calculator

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

About Kubernetes RBAC Risk Calculator

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

Worked example

With the default values below, Kubernetes RBAC Risk Calculator returns RBAC Risk Score of 77.5. Change any input above and every figure here is recalculated in your browser.

Inputs used

ClusterRoleBindings in the clusteraccepts 1–100,000 bindings
180 bindings
Subjects bound to cluster-adminaccepts 0–100,000 bindings
9 bindings
Roles granting verbs: ["*"]accepts 0–100,000 roles
14 roles
Roles granting resources: ["*"]accepts 0–100,000 roles
11 roles
Roles granting escalate or bindaccepts 0–100,000 roles
4 roles
Roles that can read secrets cluster-wideaccepts 0–100,000 roles
23 roles
Service accounts in the clusteraccepts 1–500,000 accounts
420 accounts
Service accounts bound to a ClusterRoleaccepts 0–500,000 accounts
38 accounts
Namespaces in the clusteraccepts 1–20,000 namespaces
64 namespaces

Results

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%
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

  1. 1Values used
  2. 2Kubernetes RBAC Risk
  3. 3Density normalisation
  4. 4RBAC Risk Score= 77.5 / 100
  5. 5Risk Level= High
  6. 6Weighted Risk Points= 279 points
  7. 7Risk Points per 100 Bindings= 155.0
  8. 8Cluster-Admin Binding Ratio= 5.00
  9. 9Wildcard Role Ratio= 13.9

Assumptions and limits

  • The result is derived only from the 9 inputs listed above. Anything not among them is not part of the calculation.
  • In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
  • Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

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.

Related Calculators

Kubernetes RBAC Risk Calculator | Calcrivo