RBAC

RBAC: who can do what

Sextant answers the usual access-control questions without reading Roles and bindings by hand: what can this service account (user, group) do, who can delete Secrets in prod, and can I exec into this pod. Everything here is read-only: nothing in the cluster changes.

Contents: Two kinds of answer · The Permissions page · Subject · Who can · Can I · In the details · How the rules are read · Limits

Two kinds of answer

Answer	Comes from	Good for
Computed (the Subject and Who can tabs, the details sections)	Roles, ClusterRoles, RoleBindings and ClusterRoleBindings as Sextant reads them	Any subject: a service account, a user, a group; reverse questions ("who can…")
Authoritative (the Can I tab)	The API server itself (SelfSubjectAccessReview and SelfSubjectRulesReview)	You, with the credentials you are connected with

A computed answer covers RBAC only. The API server may use other authorizers too (the Node authorizer, webhooks, ABAC), and members of the group system:masters may do everything whatever RBAC says. The page says this next to every computed view. For your own permissions, Can I is what your requests will actually get.

The Permissions page

Open Access Control → Permissions. It has three tabs: Subject, Who can and Can I.

Roles and RoleBindings are read only in the namespaces of the namespace filter (the page says which); ClusterRoles and ClusterRoleBindings always. If you may not list one of these kinds, the page says which permissions are therefore missing instead of showing them as "none".

Subject

1. Pick a subject from the list of users, groups and service accounts that bindings name (with a search box), or choose Another subject and type its kind, name, namespace (for a service account) and, for a user, the groups you know it is in. Kubernetes does not store users and groups: a user's groups come from how they sign in.
2. Choose the Namespace: All namespaces, or one namespace to see what the subject may do there (cluster-wide grants included).
3. Read the matrix: verbs × resources, grouped by API group, with non-resource URLs at the end. A marked cell is allowed; a half-marked one only for some named objects. Hover a cell to see which bindings allow it; click it to list the grants under the table: the binding, the role, where it applies (Everywhere, or Only in a namespace), through which subject entry, the rule and what its wildcards mean.

A service account also counts as a member of system:serviceaccounts, system:serviceaccounts:<namespace> and system:authenticated, so bindings to those groups are included.

Who can

Ask the reverse question: a verb on a resource (for example delete on secrets, or create on pods with the subresource exec), optionally an object name and a namespace, or a non-resource URL such as /healthz. Resources are typed as kubectl names them: pods, deployments.apps, *. Find lists every subject allowed, through which binding and role, with a link to that subject's permissions. If the resource is cluster-scoped, the page reminds you that only ClusterRoleBindings can grant it.

Can I

• Can I…: type a verb, a resource (with an optional subresource, object name and namespace) and press Ask. The answer is Yes, allowed, No, denied or No, not allowed, with the reason the API server gave.
• My permissions in a namespace: pick a namespace and press List my permissions. The API server lists what you may do there, shown as the same matrix. Some authorizers cannot list their rules; then the page says the list may be incomplete.

Questions are sent only when you press the button. Asking creates review objects that the API server answers and discards; nothing is stored in the cluster.

In the details

• Role and ClusterRole: Rules explained (what each wildcard, subresource and named object means, and the rules an aggregated ClusterRole collects from others), and Bound to: the bindings that grant it.
• RoleBinding and ClusterRoleBinding: what the binding grants and where ("Only in the namespace shop" or "In every namespace and on cluster-scoped resources"), a warning when its role does not exist, and the permissions of its subjects.
• ServiceAccount: What it can do, with Open in Permissions.

How the rules are read

Sextant follows the Kubernetes RBAC rules:

• * in resources covers every resource and every subresource; pods does not cover pods/exec or pods/log; */scale covers the scale subresource of any resource.
• A rule with resourceNames allows only requests that name one of those objects, so never create or deletecollection, and list or watch only with a field selector naming one of them.
• A ClusterRoleBinding grants its ClusterRole everywhere. A RoleBinding grants its Role — or the ClusterRole it refers to — only in its own namespace, and never cluster-scoped resources (nodes, namespaces, persistent volumes) or non-resource URLs.
• An aggregated ClusterRole holds the rules of the ClusterRoles its selectors match; a rule the controller has not copied in yet is marked as such.
• Verbs that let a subject give itself more than it has (escalate, bind, impersonate) are pointed out.

Limits

• The matrix shows at most 500 resources and Who can at most 1000 grants; the page says when it cut.
• Only subjects named in bindings are listed; anyone else can be typed in.
• AI agents can ask for the computed view (what a subject may do, who may do an action) with the read-only get_permissions tool, from the RBAC lists their rules let them read and with the lists they could not read named (see Diagnostic tools). Can I is never available to them: it describes your own credentials. Extensions can use none of it.

Next: Using Sextant.