Who Has Access to What? Making Sense of Kubernetes RBAC with the Security Matrix

Kubernetes RBAC is one of the most important things to get right in a cluster, and one of the hardest to reason about. The rules that decide who can read your Secrets, delete your Deployments, or escalate to cluster-admin are spread across ServiceAccounts, Roles, ClusterRoles, and two kinds of bindings — often in different namespaces, written by different people, over a long stretch of time. Ask a simple question like "who can read Secrets in production?" and you will find yourself grepping through YAML and stitching the answer together by hand.

This post walks through how Kubernetes RBAC actually fits together, why there is no built-in answer to "who has access to what," and how Kubexer's Security Matrix turns that scattered configuration into a single, readable grid.

Why RBAC is so hard to see

Kubernetes deliberately splits authorization into small, composable pieces. That composability is a strength — you can grant exactly the access you intend — but it also means the picture of "effective access" is never written down in one place. It is implied by the combination of every role and every binding that touches a subject.

There is no native command that answers "show me everyone who can do anything in this namespace, and what they can do." kubectl auth can-i answers a single yes/no question for one verb on one resource. kubectl get rolebindings lists bindings but not the rules they ultimately grant. The full answer requires reading every binding, resolving the role it points at, and folding all of those policy rules together per subject. Nobody does that by hand for a real cluster.

The building blocks: subjects, roles, and bindings

RBAC has exactly four object types, and once they click the whole model is approachable.

Subjects: who is asking

A subject is the identity making a request. Kubernetes recognizes three kinds:

• ServiceAccounts — namespaced identities used by workloads (and tooling) inside the cluster. Every namespace gets a default ServiceAccount automatically, and any Pod that does not name one runs as it.
• Users — external human identities. Kubernetes has no User object; users come from your authentication layer (certificates, OIDC, your cloud provider) and are just strings to RBAC.
• Groups — collections of users, also supplied by your auth layer, that let you grant access to many people at once.

Roles and ClusterRoles: what is allowed

A Role is a namespaced set of permissions — a list of policy rules over API groups, resources, and verbs. A ClusterRole is the same idea but cluster-scoped, and it can also cover cluster-scoped resources (like Nodes or PersistentVolumes) and non-resource URLs. A single rule looks like this:

rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]

Roles only grant; there are no deny rules in RBAC. Access is the union of everything granted, which is precisely why effective access is hard to eyeball — you have to add up every rule that reaches a subject.

RoleBindings and ClusterRoleBindings: who gets what, and where

Bindings are the glue that connects subjects to roles, and the scoping rules here trip up almost everyone:

• A RoleBinding grants the referenced role's permissions within its own namespace. It can reference a Role in that namespace, or — importantly — a ClusterRole.
• When a RoleBinding references a ClusterRole, the permissions apply only in the binding's namespace, not cluster-wide. This is the single most misunderstood corner of RBAC: a ClusterRole is just a reusable permission template until something binds it, and a RoleBinding scopes it down to one namespace.
• A ClusterRoleBinding grants a ClusterRole's permissions across every namespace and at the cluster level. This is the one to watch — a ClusterRoleBinding to a broad ClusterRole is how subjects quietly end up with cluster-admin-like reach.

So "what can this subject do?" depends on the role's rules, the binding type, and the binding's namespace — three things, never written together.

Where this goes wrong in practice

A few failure modes show up again and again:

• Over-broad ClusterRoleBindings. Someone binds a subject to cluster-admin or a wildcard ClusterRole (* verbs on * resources in * groups) "just to unblock a deploy," and it never gets walked back.
• Unexpected Secret access. Read access to Secrets is effectively read access to credentials. It is easy to grant get/list on Secrets via a convenience role without realizing how far that reaches.
• The default ServiceAccount. Because every Pod without an explicit ServiceAccount runs as default, any binding to default silently applies to a lot of workloads.
• Orphaned and unbound accounts. ServiceAccounts that exist but have no bindings (often leftovers) add noise, while bindings that point at deleted subjects add risk.

None of these are visible from a single screen with stock tooling. You only find them when you go looking — or after an incident.

How the Security Matrix makes access visible

Kubexer's Security Matrix is built to answer the question RBAC never answers directly: who can do what, where. It aggregates all of your RBAC — ServiceAccounts, users, groups, Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings — resolves every binding to the rules it grants, and lays the result out as one grid with subjects as rows.

Two views of the same truth

• By Namespace — columns are namespaces, plus a pinned cluster-wide column for permissions that apply everywhere. Each cell shows a subject's effective access level in that namespace, so you can scan a row to see exactly how far one identity reaches across the cluster.
• By Resource — columns are resource kinds like Pods, Secrets, and Deployments. Each cell shows the effective access a subject has on that kind, which makes questions like "who can touch Secrets?" a single glance down a column.

Color-coded levels and the markers that matter

Cells are color-coded by access level — read, write, or admin — so the shape of your RBAC jumps out before you read a single rule. The matrix also calls out the access that carries the most risk: it marks subjects that can read Secrets, and flags cluster-admin-like rules (wildcard verbs on wildcard resources in wildcard API groups). A wall of admin-colored cells or a column of Secret-readers is a finding you can act on immediately.

Drill into any cell

A grid that only shows colors would raise questions without answering them, so every cell is clickable. Drilling into a cell reveals exactly why the access exists — the specific RoleBindings and ClusterRoleBindings involved, the Roles and ClusterRoles they reference, and the underlying policy rules. That is the difference between "this looks too broad" and "this RoleBinding in payments grants the platform ServiceAccount write on Secrets via the editor ClusterRole — let's scope it down."

Unbound ServiceAccounts and on-demand snapshots

The matrix also surfaces ServiceAccounts that exist but have no RBAC at all — "unbound" accounts that are usually cleanup candidates. The whole view is a snapshot built on demand: hit Refresh and Kubexer re-reads the current RBAC and rebuilds the grid. It is entirely read-only — a visualization of what your cluster already says, derived as a heuristic from the rules in the bound roles. It does not run live SubjectAccessReview checks, and it never modifies a single object.

Putting it to work: a least-privilege review

The Security Matrix turns an RBAC audit from an archaeology project into a short, repeatable pass:

• Open By Resource and scan the Secrets column — anyone there can read credentials. Confirm each one needs it.
• Switch to By Namespace and look for rows lit up across many namespaces or in the cluster-wide column — that breadth should be deliberate, not accidental.
• Chase the cluster-admin markers. Click through to the binding and confirm the wildcard reach is intentional.
• Note the unbound ServiceAccounts and decide whether to remove them.
• For anything surprising, click the cell, read the rules, and tighten the role or binding toward least privilege.

Least privilege is only achievable if you can see the privilege you have granted. Kubernetes gives you the controls; it just never gave you the picture.

Wrapping up

RBAC's composable design is exactly what makes it both powerful and opaque: effective access is the sum of every role and binding that touches a subject, and that sum is never written down. The Security Matrix computes it for you and lays it out as a grid you can actually read — two views, color-coded levels, Secret and cluster-admin markers, drill-down to the exact rules, and a flag for unbound accounts. If you want to know who can do what, where, in your cluster, try Kubexer and let the matrix show you.