Effective Kubernetes access with the RBAC extension

An operator is handed access to a Kubernetes cluster. Working out what that access actually covers is harder than it should be.

The usual way to find out is to try something and watch for an error with code 403. That would work, but it's slow. The obvious alternative is to read the Roles and RoleBindings that apply, but listing those objects is itself something RBAC controls, and a user with limited access usually can't. So an account often can't read the rules that define its own access.

Kubernetes has its own answer to this. The SelfSubject* review APIs are the one part of the authorization system every authenticated user can always call about themselves. The apiserver works out a user's real access on the server, across every Role and binding that touches them or their groups, and hands back the answer. kubectl exposes them as auth whoami and auth can-i --list, so the information is already available. Identity comes back in one call; permissions don't - can-i --list only answers for the current namespace, so seeing access across a cluster means rerunning it per namespace and reading the text output line by line.

The RBAC extension takes these APIs and makes them easy to read. It rides whatever cluster is already selected in Kunobi, so there's no separate connection to set up. Everything below is that same SelfSubject* data in a readable layout.

Identity

Every access decision starts from who the cluster thinks the user is, so that identity is worth pinning down first.

The username shown here is the identity the apiserver authenticated, which is often different from a GitHub login or a Kunobi login. On a cluster using OpenID Connect it's typically an email, mapped from a token claim. This is the name RBAC bindings are written against, so it's worth confirming which identity that is. The status dot next to it reflects a live probe: the extension only calls a cluster "connected" once it has actually reached it.

Opening the row shows the detail behind the summary.

Almost none of the access is granted to the user directly. It arrives through group membership, each group potentially bound to a different set of roles, and the combined set is the actual access. system:authenticated is added by the apiserver to every request from a user who has logged in. The grants below the groups cover URL paths that aren't Kubernetes objects at all, things like /healthz and /version, which RBAC handles separately from resources.

Effective permissions

The Overview lists everything the authenticated identity can do on this cluster.

Each row is a resource in a namespace, and the verbs form a matrix, with granted actions in green and the rest in grey. This is the same information kubectl auth can-i --list returns, but presented as a sortable, searchable grid instead of verb lists pulled out of aligned text. Scanning the delete column to see everywhere a delete is possible is awkward in the raw text output.

Selecting a grant opens the rules behind it.

A single cell in the matrix is often the sum of more than one rule, and the detail panel keeps them separate instead of merging them. Here the get on config maps comes from two rules at once: a broad one granting get, list, and watch on every object, and a narrower one that also grants get but only on two named config maps, app-config and feature-flags. The narrow rule, scoped to those two names, allows reading only app-config and feature-flags, while the broad one would cover every config map in the namespace.

Access by namespace

The Namespaces view lists every namespace on the cluster, each with a count of the distinct resources reachable in it and the namespace's phase. Here that's 5 in default and 3 each in flux-system, kube-system, and monitoring. A namespace that grants nothing shows a zero.

Breaking access down by namespace follows directly from the API. SelfSubjectRulesReview only answers for one namespace at a time; there is no single call that returns every rule everywhere. The extension probes each namespace separately and shows the results the same way, without collapsing them into one total.

Drilling into a namespace narrows the same grid to just that one.

Errors and partial results

When a probe fails, an empty table is misleading. It reads as "no access", when the real state is that the check itself couldn't run.

When a probe is refused or times out, the extension shows the apiserver's own message as a banner instead of an empty result, so a forbidden namespace listing or an unreachable cluster says so directly. Partial answers work the same way: when the server marks a rules review as incomplete, the view keeps that state instead of showing it as complete.

How the extension works

The extension doesn't link a Kubernetes client or maintain its own connection. It reads the active cluster from Kunobi, shells out to kubectl against that context's kubeconfig, and writes the results into a few stores the views read from.

Two things come from this design. Because the apiserver works out access on the server, a user with only view access who can't read a single RoleBinding still gets a complete, correct answer, which is what the SelfSubject* APIs are for. And because probing only runs while an RBAC view is open, there's no background process calling kubectl on a timer.

Wrapping up

The RBAC extension is a read-only view over the SelfSubject* APIs: identity, effective permissions, and namespace-scoped access, laid out as sortable tables instead of kubectl output read line by line and rerun by hand. Because the apiserver computes access on the server, the answer is complete and correct even for an account that can't read a single RoleBinding - which is exactly the account this is built for.

Kunobi is free to download at kunobi.ninja.