Skip to main content

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.

Category: Kubernetes

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` grants nothing, and where the error names the missing role
  • 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

Topics covered: kubernetes, rbac, security, permissions, debugging, devops, educational, interactive

// simulator

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.

Supported byBecome a sponsor
BitriseAtomsizedDigitalOceanDevDojoSMTPfastQuizAPI

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
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.

Overview

Kubernetes RBAC answers one question: can this subject perform this verb on this resource in this namespace? kubectl auth can-i gives a yes or a no, but it does not tell you which binding granted the permission or why the binding you were sure about did not apply. This simulator answers the why. You pick a subject, a verb, a resource and a namespace, and it evaluates the Roles, ClusterRoles, RoleBindings and ClusterRoleBindings in the scenario and shows the rule that matched or the reason nothing did. The scenarios cover the behaviors that confuse people most. A ClusterRole bound with a RoleBinding only grants access inside that RoleBinding namespace. Nodes are not namespaced, so a RoleBinding can never grant them. A rule limited by resourceNames allows getting one secret but not listing them all. A roleRef that points to a role that does not exist grants nothing, and the simulator names the missing role. And there are no deny rules in RBAC: permissions only add up, so an unwanted permission is always explained by some rule that allows it.

Try this

  1. Open "The one that surprises everyone" and ask whether the CI service account can list pods in a namespace other than dev.
  2. Pick the "Nodes are not in a namespace" scenario and see why a RoleBinding cannot grant access to nodes.
  3. Try "One secret, not the list" and compare the answer for get on the named secret with list on all secrets.

Frequently asked questions

What is the difference between a Role and a ClusterRole?
A Role defines permissions inside one namespace. A ClusterRole defines permissions that can be used in any namespace, and it is the only way to describe access to cluster-scoped resources such as nodes.
What happens when you bind a ClusterRole with a RoleBinding?
The permissions apply only inside the namespace of the RoleBinding. This is a common way to reuse one ClusterRole definition across many namespaces without granting cluster-wide access.
Can you deny a permission in Kubernetes RBAC?
No. RBAC rules are purely additive. To remove access you have to remove or narrow the rule or binding that grants it.
How do I check what a service account can do?
Use kubectl auth can-i with --as, for example kubectl auth can-i list pods --as=system:serviceaccount:dev:ci -n dev. It answers yes or no, so you still need to read the bindings to find out why.

Try next

Sponsored
Carbon Ads
$ cd /games
// share