Before we meet the solution, let us feel the trouble it removes. A safety tool only makes sense once you imagine the accident.

A quick look at Kubernetes

A container is a small sealed box holding a program and everything it needs. Kubernetes is the free, open-source system that starts, stops, moves and repairs thousands of these boxes across many computers. A group of computers managed together is a cluster. Containers run inside small wrappers called Pods. Everything you do to a cluster, such as creating a Pod or reading a password, is done by sending a request to its front door, the API server.

Why unlimited access is dangerous

If every person and every program could ask the API server for anything, small mistakes and small attacks would become huge.

• A developer who only meant to look at one app’s Pods accidentally deletes the whole production database.
• A tool that only needs to read the list of Pods is hacked, and the attacker uses its unlimited power to steal every password in the cluster.
• A former employee’s account still works months after they left, and it can do everything.
• Two teams share one cluster, and one team can read the other team’s private data.

The fix is a rule that has been used in security for decades: the principle of least privilege. It means every person and every program should have only the permissions they need to do their job, and no more.

Eight small ideas carry this whole topic. Learn them once and everything else will feel natural.

RBAC is only one gate in a row of three. Knowing the other two prevents a lot of confusion.

When you send a request to the API server, it does not simply obey. The request must pass three gates, one after another. If it fails any gate, it stops there.

Important: Kubernetes does not store your users

Beginners are often surprised to learn that Kubernetes has no built-in list of human users. There is no place to “create a user” and give them a password. Instead, the cluster trusts outside systems to prove identities: signed certificates, tokens from a company login service, or the cloud provider’s identity system. RBAC then works with the name and groups that these systems report. Programs inside the cluster are different: they use service accounts, which are real objects that Kubernetes manages.

Let us define it in plain words and then note the three facts that shape everything else.

RBAC is the part of Kubernetes that decides, for every request, whether the person or program asking is allowed to do it. Instead of giving permissions directly to each person, you gather permissions into named bundles called roles, and then connect people to roles. Roles describe “what can be done”. Bindings describe “who gets it”. Keeping these two ideas apart makes access easy to manage.

RBAC has been a stable, standard feature of Kubernetes since 2017, and nearly every real cluster uses it. It is normally switched on by starting the API server with RBAC as one of its authorization modes.

Three facts to remember

• Everything is denied by default. If no rule allows a request, it is refused. A brand new person with no bindings can do nothing.
• RBAC only adds permissions. There is no “deny” rule. The full set of permissions someone has is the sum of every rule from every role they are bound to.
• Permissions can be checked, listed and changed at any time. A change to a role takes effect quickly for everyone bound to it.

Everything in RBAC is built from four simple objects. They come in two pairs.

Here is the whole picture in one drawing. Follow the arrows from the people on the left to the resources on the right.

flowchart LR
    subgraph WHO["Subjects: who is asking"]
        U["User"]
        G["Group"]
        SA["ServiceAccount"]
    end
    subgraph BIND["Bindings: the links"]
        RB["RoleBinding: one namespace"]
        CRB["ClusterRoleBinding: whole cluster"]
    end
    subgraph WHAT["Roles: what is allowed"]
        R["Role: one namespace"]
        CR["ClusterRole: cluster wide"]
    end
    U --> RB
    G --> RB
    SA --> RB
    U --> CRB
    G --> CRB
    SA --> CRB
    RB --> R
    RB --> CR
    CRB --> CR
    R --> RULE["Rules: verbs on resources"]
    CR --> RULE
    RULE --> RES["Kubernetes resources such as Pods, Secrets and Nodes"]
    

Reading the diagram

Read it from left to right as a chain of trust. On the far left are the subjects: the people, groups and programs that make requests. In the middle are the bindings, which connect each subject to a role. Next come the roles, which hold rules. And on the right are the resources that the rules talk about. To find out what someone can do, you follow the arrows from them to the end and collect every rule you meet.

Notice that a RoleBinding can point to either a Role or a ClusterRole. That is a clever trick we will explore later. It lets you write a permission bundle once and hand it out room by room.

Meet each component

What actually happens between pressing Enter and getting an answer? Let us walk through it slowly.

sequenceDiagram
    participant U as You
    participant A as API Server
    participant N as Authentication
    participant R as RBAC Authorizer
    participant M as Admission Control
    participant S as Cluster Storage
    U->>A: Send a request
    A->>N: Who is this
    N-->>A: This is Ravi in group team-a
    A->>R: May Ravi do this action here
    R-->>A: Yes, a rule allows it
    A->>M: Check policies and defaults
    M-->>A: Accepted
    A->>S: Save the change
    A-->>U: Success
    

A role is just a list of rules. Each rule answers three questions: which kind of thing, which actions, and optionally which named items.

The parts of a rule

The verbs, in plain words

Sub-resources: the hidden doors

Some resources have hidden parts with their own permissions. Reading a Pod’s logs is one permission, and opening a shell inside a Pod is another. Being able to look at a Pod does not mean you can see its logs, and being able to see logs does not mean you can step inside it. This lets you grant “read-only debugging” without granting “get inside and change things”.

A permission is only useful when it is attached to a subject. There are three kinds, and each has its own habits.

Users

A user is a human being, identified by a name that an outside system supplies. This might come from a signed certificate, from your company’s login service using a standard called OpenID Connect, or from the cloud provider’s identity system. Kubernetes does not store passwords for users. It only trusts the identity that it is told about.

Groups

Groups come from the same outside systems. A person’s request may carry several group names, such as “team-a” and “developers”. Binding a role to a group means that new team members get the right access automatically when they join the group, and lose it when they leave. Kubernetes also adds a few special groups of its own. Everyone who has proved their identity belongs to the group “system:authenticated”, and a group called “system:masters” is hard-wired to have unlimited power that RBAC cannot take away.

Service accounts

A service account is the identity of a program running in a Pod. Each namespace gets a default service account, and Pods use it automatically unless told otherwise. When a program inside the cluster needs to call the API server, for example a tool that watches for new Deployments, it does so as its service account. Its full name looks like “system:serviceaccount:” followed by the namespace and the account name. Modern clusters give each Pod a short-lived, automatically rotated token instead of a permanent password.

The same role can behave very differently depending on how you bind it. This is the most useful trick in RBAC.

flowchart LR
    CR["ClusterRole: view"] --> RB1["RoleBinding in namespace shop"]
    CR --> RB2["RoleBinding in namespace blog"]
    CR --> CRB["ClusterRoleBinding"]
    RB1 --> S1["Read access in shop only"]
    RB2 --> S2["Read access in blog only"]
    CRB --> S3["Read access in every namespace"]
    

Suppose you write a ClusterRole called “view” that allows reading most things. If you attach it with a RoleBinding in the shop namespace, the person can read only inside the shop. Attach the same ClusterRole with a RoleBinding in the blog namespace and they can read only in the blog. Attach it with a ClusterRoleBinding and they can read everywhere. The bundle is the same; only the reach changes.

When you truly need a ClusterRole

• Some resources do not belong to any namespace, such as Nodes, PersistentVolumes and Namespaces themselves. Permissions on these need a ClusterRole and a ClusterRoleBinding.
• Some web addresses of the API server are not resources at all, such as health checks. Rules for those also live in a ClusterRole.
• When you want one shared bundle reused in many namespaces, define it once as a ClusterRole and bind it room by room.

flowchart TB
    Q["What access do you need to give"] --> A["One namespace only"]
    Q --> B["Every namespace"]
    Q --> C["Cluster-level things such as Nodes"]
    A --> A1["Role plus RoleBinding, or a ClusterRole plus a RoleBinding"]
    B --> B1["ClusterRole plus ClusterRoleBinding"]
    C --> C1["ClusterRole plus ClusterRoleBinding"]
    

You do not have to write every role from scratch. Kubernetes ships with a handful of ready-made ClusterRoles, and understanding them saves a lot of work.

How they combine with bindings

These are ClusterRoles, so you choose their reach with the kind of binding. Attach “edit” to a group with a RoleBinding in one namespace and the whole team can deploy apps there and nowhere else. Attach “cluster-admin” with a ClusterRoleBinding and you have created a super administrator. The built-in “cluster-admin” role is already linked to the special group “system:masters”.

System roles

You will also see many roles whose names start with “system:”. Kubernetes creates them for its own components, such as the scheduler and the controller manager, so that each part of the cluster has only the access it needs. It is best not to edit or delete them, since the cluster relies on them.

Roles that grow automatically

The admin, edit and view roles are built by aggregation. Extension authors can attach labels to their own ClusterRoles, and Kubernetes merges those permissions into the built-in ones. That way, when you install a new kind of resource, the familiar view and edit roles learn about it without manual work.

Let us put the pieces together with a story. No commands, just the thinking, so you can see how the decisions flow.

Sooner or later you will see a “forbidden” message. Knowing how to read it and test the fix is a core skill.

Reading a forbidden message

A refusal usually tells you four things in plain words: who was refused, which action, which kind of resource, and in which namespace. For instance, it may say that a certain user cannot list Pods in a certain namespace. Those four facts are exactly what RBAC checked, so they point straight to the missing rule.

Helpful community tools

Several open-source tools make access easier to inspect. Some show a matrix of what a subject can do across all resources, and others answer “who can delete Secrets in this namespace?” or “which roles does this person hold?”. Names you may meet include rakkess, kubectl-who-can and rbac-lookup.

Real teams do not create user accounts in Kubernetes. They connect the cluster to an identity system they already trust.

Two layers of doors

On managed clouds there are usually two separate sets of permissions. One decides who can reach and manage the cluster as a cloud resource, such as creating or deleting the whole cluster. The other, RBAC, decides what they can do inside it, such as deleting a Pod. You must set up both. Being an administrator in the cloud account does not always give the same power inside the cluster, and the reverse is true too.

Every design has strengths and costs. Knowing both helps you decide well.

The trade-offs behind the choices

Safety versus convenience. Giving broad roles makes life easy today and risky tomorrow. Narrow roles take more design and testing, but limit the damage from any mistake.

Few roles versus many roles. A small set of well-known roles is easy to understand and audit. A huge collection of tiny custom roles is precise but hard to keep track of. Most teams settle on the built-in roles for common needs and a few custom ones for special cases.

Cluster-wide versus namespace-level. Cluster-wide bindings are simple to manage but expose everything. Namespace-level bindings need more objects but contain any problem to one room.

RBAC alone versus extra policy tools. Because RBAC cannot express conditions, larger organizations add policy engines that check requests against extra rules. This gives more control at the cost of more moving parts.

Some permissions sound harmless but can be turned into full control. Learning to spot them is what separates careful teams from careless ones.

Guards built into RBAC

Kubernetes includes protection against a person quietly raising their own power. You can create or change a role only if you already hold every permission that role contains, unless you have been granted the special escalate verb. In the same way, you can create a binding only if you already hold the permissions being handed out, unless you have the bind verb. These guards are why the special verbs are so sensitive.

Habits that reduce risk

• Turn off the automatic token for Pods that never call the API server.
• Give each application its own service account instead of sharing the default one.
• Do not bind roles to the groups of anonymous or unauthenticated users.
• Avoid using the powerful “system:masters” group for everyday work. It bypasses RBAC completely and cannot be limited.
• Use short-lived credentials instead of permanent ones wherever possible.

Access is not a set-it-and-forget-it job. Permissions tend to grow silently, so you need to keep looking at them.

Alarms worth setting

• Any new binding that grants cluster-admin.
• Any edit to a built-in or system role.
• Any use of impersonation, escalation or the bind verb.
• A large jump in refused requests from one identity.
• Reading of Secrets by identities that normally never do.

Patterns are solutions that many teams found reliable. Anti-patterns are traps many teams fell into.

Patterns that work

Traps to avoid

Small habits make the difference between tidy, safe access and a tangle nobody dares to touch.

Habits that pay off

• Apply least privilege. Start with no access and add only what is proven necessary.
• Prefer namespace-level bindings. Reach for cluster-wide bindings only when a resource truly needs it.
• Use the built-in roles first. Admin, edit and view cover most human needs.
• Name roles clearly. A name like “deployment-updater-shop” explains itself. A name like “role1” does not.
• Document why. Add a note on each custom role saying who asked for it and for what purpose.
• Test as the subject. Verify that allowed actions work and forbidden ones fail, before and after each change.
• Keep access in version control. Review changes just like code.
• Review regularly. Remove stale bindings, old service accounts and departed people.
• Protect the special verbs. Treat escalate, bind, impersonate and token creation like administrator powers.

Mistakes beginners make

Here is how RBAC shows up in everyday practice across popular tools and common team setups.

Quick answers to the questions beginners ask most often.

You began with a building where everyone held the master key. Now you know how to issue the right key card to the right person.