Buy me a Koffee
RBAC Effective Permissions Visualizer
Paste any combination of Role, ClusterRole, RoleBinding and ClusterRoleBinding YAML. This tool resolves the effective, additive permissions for every subject, and shows exactly which binding granted each one — including correct namespace scoping for RoleBinding-to-ClusterRole and resolved aggregated ClusterRoles.
Everything runs in your browser. Your manifests are never uploaded anywhere.
Paste RBAC YAML (multi-document, --- separated)
RBAC Is Purely Additive — There Is No Deny Rule
Kubernetes RBAC has exactly one operation: grant. A subject's effective permission for any (namespace, resource, verb) combination is the union of every rule granted by every RoleBinding or ClusterRoleBinding that names that subject. There is no explicit deny, no rule priority, and no way for one binding to override or subtract from another. If any single binding grants delete on pods, that subject can delete pods, even if ten other bindings say nothing about pods at all. This tool implements exactly that: it never treats a missing rule as a deny, only ever as "not yet granted," and it unions every applicable rule from every binding you paste in.
Gotcha: A RoleBinding to a ClusterRole Is Still Namespace-Scoped
It is completely normal, and common, to bind a ClusterRole using a RoleBinding rather than a ClusterRoleBinding — this is the standard way to reuse one rule set (like a built-in edit or view ClusterRole) across many namespaces without duplicating YAML. The part that trips engineers up is what scope that grants: a RoleBinding always scopes whatever it grants to its own namespace, regardless of whether roleRef points to a Role or a ClusterRole. Binding the cluster-admin ClusterRole via a RoleBinding in the staging namespace grants admin rights inside staging only, not cluster-wide. Only a ClusterRoleBinding grants access across every namespace. This tool resolves that scoping correctly and flags it inline wherever it applies.
Gotcha: Aggregated ClusterRoles Merge Rules From Elsewhere
A ClusterRole can define aggregationRule.clusterRoleSelectors instead of (or alongside) its own rules. The control plane continuously scans for any other ClusterRole whose metadata.labels match those selectors and merges that role's rules in automatically — this is exactly how add-ons extend the built-in admin and edit ClusterRoles without anyone editing them directly. Reading an aggregating ClusterRole's own YAML in isolation is misleading: its real, effective permissions live partly in whatever ClusterRoles elsewhere in the cluster happen to carry the matching label. This tool resolves aggregation across everything you paste, in any order, and clearly warns you when a selector matches nothing in your input so you know the picture may be incomplete.