Kubernetes RBAC Simulator

Ask whether a service account can do a verb on a resource in a namespace, and get the reason rather than a yes or no. Covers the ClusterRole bound by a RoleBinding that is silently confined to one namespace, why resourceNames grants get but never list, the dangling roleRef that fails without an error, and the fact that RBAC has no deny rules. Every answer prints the matching kubectl auth can-i command. The engine is real and runs in your browser.

What You Will Learn

Why a ClusterRole bound with a RoleBinding only works in one namespace
The difference between Role and ClusterRole, and RoleBinding and ClusterRoleBinding
Why a namespaced binding can never grant access to nodes or other cluster-scoped resources
Why `resourceNames` lets you `get` an object but never `list` the collection
That RBAC has no deny rules, so permissions only ever add
Why a typo in a `roleRef` fails silently, with no error and no event
How a ServiceAccount is identified, and why its namespace is part of its name
What an empty `apiGroups: [""]` means, and when you need `apps` instead
How to ask the same question of a real cluster with `kubectl auth can-i`
How to read a denial and find the binding that was supposed to grant it

This interactive simulator requires JavaScript to run. Please enable JavaScript in your browser to use this tool.

// simulator

Kubernetes RBAC Simulator

Supported byBecome a sponsor

A Role and a RoleBinding in the same namespace. Everything applies exactly where you put it, which is the mental model people then over-apply.

The cluster1 role, 1 binding

kind: Role
metadata:
  name: pod-reader
  namespace: dev
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

kind: RoleBinding
metadata:
  name: ci-reads-pods
  namespace: dev
roleRef:
  kind: Role
  name: pod-reader
subjects:
  - kind: ServiceAccount
    name: ci
    namespace: dev

Can this subject

subject

verb

resource

namespace

named object, optional

Allowed

Yes. ServiceAccount dev/ci can list pods in dev, granted by RoleBinding/ci-reads-pods through Role/pod-reader, which applies to namespace dev.

getlistwatchcreateupdatepatchdeletedeletecollection

Every verb this subject has on pods in dev. RBAC has no deny rules, so this list only ever grows as bindings are added.

kubectl auth can-i list pods -n dev --as=system:serviceaccount:dev:ci

The same question, asked of a real cluster. Impersonation needs a user who can impersonate, which is usually a cluster admin.

About this Kubernetes RBAC simulator

What you'll learn

That the answer to "why can this service account not list pods" is almost always about scope, not about the rules
That a ClusterRole is cluster-wide in definition and only as wide as the binding that grants it
That there is no deny rule to find, so a refusal means nothing granted it in the first place
The mistakes that produce silence instead of an error, which are the expensive ones

How it works

The evaluation is real and runs in your browser. Nothing here is a canned answer.
Every answer names the binding and rule responsible, or explains why each candidate did not apply.
Each question prints the matching `kubectl auth can-i`, so it teaches the real tool.
Change the namespace on the same cluster and watch the answer flip.

The behaviour here follows the Kubernetes RBAC documentation. One detail is worth stating plainly because it is the source of most confusion: a RoleBinding can reference a ClusterRole, and when it does, the permissions apply only inside that RoleBinding's namespace. The role is defined once and granted narrowly. That is a feature, since it lets you define view or edit once and hand them out per namespace, but it catches people who expect "cluster" in the name to mean cluster-wide.

Reading about RBAC only gets you so far, and the fastest way to make it stick is to break it on a cluster you do not mind breaking. A managed cluster is the cheapest way to get one: DigitalOcean Kubernetes gives you a conformant cluster in a few minutes, and RBAC behaves identically there to anywhere else, so every scenario on this page can be reproduced with kubectl apply and checked with kubectl auth can-i. That is a referral link, and DigitalOcean sponsors this site.

Related: the Kubernetes terminal simulator for the commands themselves, and the YAML parsing simulator for the other way a manifest can mean something you did not write.