Security Matrix
See who can do what across the cluster — RBAC subjects mapped to namespaces and resources in one matrix.
Security Matrix
Understand who can do what in your cluster. The Security Matrix aggregates all Kubernetes RBAC — ServiceAccounts, Users, Groups, Roles, ClusterRoles, and their bindings — into a single grid, so access is visible at a glance instead of pieced together from separate lists.
Two views
- By Namespace — rows are subjects (ServiceAccounts / Users / Groups), columns are every namespace plus a pinned Cluster-wide column. Each cell shows the subject's effective access level in that namespace. Cluster-wide grants apply in every namespace, so they light up the whole row.
- By Resource — rows are subjects, columns are common resource kinds (Pods, Secrets, Deployments, …). Each cell shows the effective access on that kind. Filter to one namespace, or leave it on "All namespaces" to see cluster-wide effective access.
Access levels
Cells are color-coded by the strongest verb the subject's bound roles grant:
- read —
get/list/watch - write —
create/update/patch/delete - admin —
*verbs, or privilege-escalation verbs (escalate/bind/impersonate)
Two markers flag risk at a glance: a lock when the subject can read Secrets, and an alert for cluster-admin-like rules (* verbs on * resources in * groups).
Drilling into a cell
Click any cell to open a drawer that shows exactly which RoleBindings and ClusterRoleBindings contribute that access, the Roles or ClusterRoles they reference, and the underlying policy rules — so you can trace a grant back to its source.
Snapshot model
The matrix is built on demand from a single pass over the cluster's RBAC. Press Refresh to rebuild after you change roles or bindings. If your account isn't allowed to list some RBAC kinds, those are surfaced as warnings and the rest of the matrix still builds.
Reading the grid
- An unbound badge marks a ServiceAccount that exists but is referenced by no RoleBinding or ClusterRoleBinding — it holds no RBAC permissions (though pods may still mount it for an identity or token).
- Hide system filters out built-in identities:
kube-*ServiceAccounts andsystem:Users/Groups. - A ban icon means the subject has no access for that cell.
Access levels are a fast heuristic for triage and review — not a replacement for the apiserver's own authorization checks.
Security Matrix is a Pro feature.