RBAC is the built-in system that decides which people and programs may perform which actions on which parts of a Kubernetes cluster.

The Simple Definition

Kubernetes is controlled entirely through requests sent to a front door called the API server. Every action, such as listing pods, creating a deployment, reading a secret, or deleting a namespace, is one of these requests. Role-based access control is the checkpoint that examines each request and answers one question: is this requester allowed to do this?

The word role is the key idea. Instead of attaching permissions directly to every individual, you gather permissions into named bundles, called roles, and then connect those bundles to people and programs. When someone changes jobs, you change which roles they hold rather than rewriting a long list of individual permissions. This makes the system easier to understand, review, and audit.

What RBAC Controls

RBAC controls access to the Kubernetes API. It decides who may read, create, change, or delete cluster objects. It does not control what happens inside a running container, and it does not decide which network traffic may flow between pods. Those are handled by other mechanisms. Keeping this boundary clear prevents a common confusion, in which people expect RBAC to protect everything.

A Short History of Why RBAC Exists

Early clusters used simple, coarse ways to decide who could do what. Access was often all or nothing: either a person could do everything, or they could do nothing. As Kubernetes spread into companies with many teams, that approach became unworkable. Teams needed to share one cluster without seeing each other’s work, and automated programs needed just enough power to do their jobs. Role-based access control grew to meet these needs and is now the standard way to authorize requests in nearly every cluster.

The lesson from that history is that permissions must be expressed in small, named, reusable pieces. A cluster with fifty applications, twenty teams, and hundreds of people cannot be managed by writing individual permissions for each person. Roles and bindings scale because they describe jobs, and jobs change far less often than people do.

A cluster holds the keys to every application, secret, and customer workload, so who may touch what is one of the most important decisions you make.

The Cost of Too Much Access

Imagine giving every employee the master key to every door because it saves time on the first day. It works until someone makes a mistake, or someone with bad intentions arrives, or a stolen key falls into the wrong hands. In a cluster, a person or program with too much power can delete production workloads, read passwords, or start hidden programs that mine currency at your expense. Most serious cluster breaches trace back to permissions that were far wider than the task required.

Three Questions Every Request Answers

When a request reaches the API server, it passes through three gates in order. Understanding them separately is essential, because people often mix them up.

flowchart LR
    R[Request arrives] --> A[Authentication: who are you?]
    A --> Z[Authorization with RBAC: are you allowed?]
    Z --> M[Admission control: is the request acceptable?]
    M --> S[Stored in the cluster]
    A -- Unknown identity --> X1[Rejected: Unauthorized]
    Z -- No matching permission --> X2[Rejected: Forbidden]
    M -- Rule violated --> X3[Rejected by policy]
        

Where Trust Begins

Every security design must decide what it trusts. In Kubernetes, the API server trusts the identity providers and certificate authorities that it has been configured with, and it trusts its own record of roles and bindings. Everything else follows from those two trusts. If an identity provider is careless about who gets a token, no amount of careful role design will help. If the records of roles and bindings can be edited by too many people, the careful design can be undone in a moment.

This is why access control is a chain, and the chain is only as strong as its weakest link. Protect the identity system, protect who can edit RBAC objects, and protect the stores where audit logs and secrets live. Roles and bindings are the visible middle of that chain, and they deserve attention, but they are not the whole of it.

Every permission in RBAC is built from the same handful of ingredients: subjects, resources, verbs, and scope.

A Permission Is a Sentence

Every RBAC permission reads like a short sentence: this subject may perform these verbs on these resources within this scope. For example, the group of developers may list and get pods in the shop namespace. If you can phrase a permission as a clear sentence like that, you can express it in RBAC, and if you cannot, the design probably needs more thought.

Namespaced and Cluster-Wide Resources

Some resources live inside a namespace, such as pods, services, and config maps. Others belong to the cluster as a whole and have no namespace, such as nodes, persistent volumes, and namespaces themselves. This difference decides which RBAC objects you need. Permissions on namespaced resources can be granted in one namespace or across all of them. Permissions on cluster-wide resources can only be granted cluster-wide.

Reading a Request the Way the Cluster Does

When a request arrives, the cluster breaks it into the same ingredients you have just met. It notes who is asking, which action is being attempted, which kind of object is involved, which specific object if any, and which namespace. It then looks for a rule that matches every one of these details. If a single detail does not match, that rule does not apply. This is why precise wording in roles matters, and why a small typing mistake in a resource name can make an entire permission useless.

Practising this mindset helps you both write and debug roles. When you read a role, imagine a request and check each detail against the rule. When you debug a refusal, write the request out in the same parts and find which one has no matching rule. Nearly every RBAC puzzle becomes simple once you view it this way.

RBAC in Kubernetes consists of just four object kinds, arranged in two pairs.

Two Pairs

The first pair defines permissions. A Role defines permissions inside one namespace. A ClusterRole defines permissions that can span the whole cluster, or that apply to cluster-wide resources. The second pair grants those permissions. A RoleBinding connects a role to subjects within one namespace. A ClusterRoleBinding connects a ClusterRole to subjects across the entire cluster.

flowchart TD
    subgraph Define[Define permissions]
        R[Role: one namespace]
        CR[ClusterRole: cluster-wide]
    end
    subgraph Grant[Grant to subjects]
        RB[RoleBinding: one namespace]
        CRB[ClusterRoleBinding: whole cluster]
    end
    R --> RB
    CR --> RB
    CR --> CRB
    RB --> S[Users, groups, service accounts]
    CRB --> S
        

Remembering the Four With a Simple Pattern

A helpful memory trick is to notice that the names follow a pattern. The word Role means the definition of permissions, and the word Binding means the granting of them. The prefix Cluster widens the scope from one namespace to the whole cluster. So a Role is a namespaced definition, a ClusterRole is a cluster-scoped definition, a RoleBinding is a namespaced grant, and a ClusterRoleBinding is a cluster-scoped grant.

With this pattern, you can work out what any RBAC object does from its name alone. It also helps when reading unfamiliar configuration: look for the word Binding to find the places where access is actually given, and look for the word Role to find where permissions are described.

A Role is a named list of rules that applies only within the namespace where it lives.

What a Role Contains

A Role has a name, a namespace, and a list of rules. Each rule says which verbs are permitted on which resources. There is no way to express a denial, only allowances. If a role has no rule that covers an action, that action is not granted by that role.

Because a Role lives in one namespace, it can only ever grant access to objects in that same namespace. A role in the shop namespace can never let anyone touch the billing namespace, no matter how it is written. This built-in limit makes namespaced roles a safe default for teams that share a cluster.

Keeping Roles Small and Focused

A common temptation is to create one large role for each team that contains everything the team might ever need. This feels tidy but hides risks. The role grows over time, nobody remembers why each rule is there, and every person bound to it receives all of it. Smaller roles with a single purpose, such as reading pods, managing config maps, or scaling deployments, are easier to understand and combine. A subject that needs several abilities simply receives several small roles.

Small roles also make reviews faster. A reviewer can look at a role called pod-reader and confirm in seconds that it does what its name says. Reviewing a giant role called team-everything takes much longer, and mistakes hide in the length. Think of small roles as building blocks that you can assemble differently for each job.

Every rule in a role or cluster role is built from the same three lists, and reading them correctly is the heart of RBAC.

API Groups, Resources, and Verbs

A rule names three things. The first is the API group, which identifies the family of resources. The core group, written as an empty name, holds pods, services, secrets, and config maps. Other groups hold deployments, ingresses, and custom kinds. The second is the list of resource kinds. The third is the list of verbs. A request is allowed by a rule only when its group, resource, and verb all appear in that rule.

This is a strict match. Permission to get pods does not give permission to get secrets. Permission to list deployments does not give permission to delete them. Each combination must be granted on purpose, which is exactly what makes the system predictable.

The Verbs Explained

The Wildcard

A rule can use a star to mean all verbs, all resources, or all groups. It is convenient and dangerous. A star on verbs means every present and future action, and a star on resources means every present and future kind, including kinds added later by extensions. Stars turn a narrow permission into a moving target, so they belong only in rare, carefully reviewed places.

Reading a Rule Step by Step

Take a rule that names the core group, the resource pods, and the verbs get and list. Read it in three passes. First ask which family of resources it covers, and note that the core group holds pods. Second ask which kinds within that family, and note that only pods are named. Third ask which actions, and note that only reading one and reading all are allowed. Put together, the rule says that the holder may look at one pod or list all pods and nothing else. It cannot see logs, cannot delete pods, and cannot touch any other kind of object.

Now imagine the rule with a star for verbs. The three passes still work, but the last pass now says every action, including deleting pods and running commands in them if that subresource is also covered. The difference between the two rules is a single word, yet the difference in power is enormous. This is why careful reading of every list in every rule is an essential skill.

A RoleBinding connects a list of subjects to a role, inside one namespace.

What a Binding Contains

A RoleBinding has three parts: a name, a list of subjects, and a reference to the role it grants. The subjects can be users, groups, or service accounts. The reference points to a Role in the same namespace, or to a ClusterRole, a trick explained in a later chapter. Once the binding exists, every subject in it receives the role’s permissions, but only in the binding’s own namespace.

Bindings Are Immutable in Their Target

After a binding is created, the role it points to cannot be changed. If you want the same subjects to have a different role, you delete the binding and create a new one. This rule prevents someone with permission to edit a binding from quietly swapping a small role for a powerful one. The role itself may still be edited, and the change flows to everyone bound to it, but the link cannot be redirected.

Namespaces as Neighbourhoods

Namespaces work like neighbourhoods in a city. Residents of one neighbourhood can freely use their own streets and shops. Visiting another neighbourhood requires an invitation. A RoleBinding is that invitation, and it works only for the neighbourhood where it was issued. If a team needs to work in three namespaces, it needs three bindings, one in each. This may feel repetitive, but it makes the boundaries visible: reading the bindings in a namespace tells you exactly who has access to it.

When you need to answer who has access to the shop namespace, you list its RoleBindings and note the subjects. You also remember to check cluster-wide bindings, since they extend into every namespace. Together, those two lists give the full answer.

A ClusterRole is a list of rules that is not tied to any single namespace.

Three Jobs of a ClusterRole

A ClusterRole does three different jobs, and beginners often see only one. First, it can grant access to cluster-wide resources such as nodes, persistent volumes, and namespaces, which cannot be covered by a namespaced role. Second, it can define a reusable set of permissions on namespaced resources, to be granted in one namespace or in all of them. Third, it can grant access to non-resource endpoints, such as health and metrics addresses of the API server.

Reading a ClusterRole Safely

When you review a ClusterRole, remember that its danger depends on who receives it and how. Begin by reading its rules and asking what the most powerful combination is. Then look for every binding that references it and note the type of each. A ClusterRole bound only through namespaced RoleBindings has limited reach. The same ClusterRole bound through a ClusterRoleBinding has full reach. The review is not complete until both halves have been examined.

It is also worth checking whether the ClusterRole carries any aggregation labels, since these may cause it to be merged into other roles you had not connected to it. A small, innocent-looking ClusterRole with the wrong label can widen a built-in role for everyone.

A ClusterRoleBinding gives a ClusterRole to subjects in every namespace at once, and for cluster-wide resources.

The Widest Grant

When you bind a ClusterRole with a ClusterRoleBinding, the permissions apply everywhere. If the ClusterRole allows reading pods, the subject can read pods in every current and future namespace. If it allows managing nodes, the subject can manage all nodes. This is the widest grant RBAC offers, and it should be used sparingly and reviewed regularly.

When It Is the Right Tool

Some subjects genuinely need cluster-wide power. A monitoring system reads pods and nodes everywhere. A cluster administrator manages everything. A controller that reacts to objects in all namespaces needs a view of all of them. These cases justify a ClusterRoleBinding. For an ordinary application team working in its own namespaces, a ClusterRoleBinding is almost always more than needed.

Cluster-Wide Bindings and the Blast Radius

Security thinkers use the phrase blast radius to describe how much damage a single compromised identity can do. A subject with a namespaced binding has a small blast radius: the damage is limited to that namespace. A subject with a cluster-wide binding has a blast radius that covers every namespace. When you decide between the two kinds of binding, the question is not only what the subject needs, but how bad things would be if its credentials were stolen tomorrow.

This way of thinking often changes decisions. A monitoring agent that only reads has a wide but shallow blast radius, which may be acceptable. A deployment tool that can change everything everywhere has a wide and deep blast radius, which usually is not. Aim to keep either the width or the depth small, and preferably both.

A RoleBinding may point to a ClusterRole, and the result is a shared definition applied within just one namespace.

Define Once, Grant Locally

Imagine twenty namespaces, each needing a subject who can view common resources. If you had to write twenty identical Roles, one per namespace, you would create clutter and risk small differences creeping in. Instead you write one ClusterRole that describes viewing, then create a RoleBinding in each namespace that points to it. The permissions apply only in the namespace of each binding, even though the definition is shared.

This is one of the most useful patterns in RBAC. It gives you the consistency of a central definition and the safety of a local grant. Updating the definition updates every namespace that uses it, and each grant remains limited to its own namespace.

flowchart TD
    CR[ClusterRole: viewer definition]
    RB1[RoleBinding in namespace shop]
    RB2[RoleBinding in namespace billing]
    RB3[RoleBinding in namespace search]
    CR --> RB1
    CR --> RB2
    CR --> RB3
    RB1 --> G1[Access only in shop]
    RB2 --> G2[Access only in billing]
    RB3 --> G3[Access only in search]
        

Choosing Between Role and ClusterRole for Reuse

When several namespaces need the same permissions, you have two options. You can write a separate Role in each namespace, or write one ClusterRole and bind it locally. The single ClusterRole is usually better, because it removes duplication and keeps definitions consistent. The separate Roles are better when the permissions genuinely differ between namespaces, such as when one namespace has extra objects that others lack.

A sensible default is to use ClusterRoles for common jobs, such as viewer, editor, and deployer, and namespaced Roles for unusual, one-off needs. This keeps the number of definitions small and the meaning of each easy to explain to newcomers.

A binding can grant permissions to three kinds of subjects, and each behaves differently.

Users

Kubernetes does not store user accounts. There is no object called a user that you can create in the cluster. Instead, users come from outside: a certificate whose subject name identifies a person, or a token issued by an identity provider. The cluster trusts the identity it is shown and uses its name as the subject in bindings. That name must match exactly, including capital letters.

Groups

Groups also come from outside. A certificate may name groups in its organization field, and an identity provider may include group names in a token. Groups are the best target for bindings, because they change with your organization chart without changes inside the cluster.

Service Accounts

Service accounts are identities for programs running inside the cluster. Unlike users, they are real objects that live in a namespace. Every pod runs as some service account, and it uses that identity when it talks to the API server. Because they represent software rather than people, they should be given very small, specific permissions.

How Identities Get Their Names

The name that appears in a binding must match the name that the authentication step produces. For certificates, the name comes from the common name field, and groups come from the organization field. For tokens issued by an identity provider, the name and groups come from claims inside the token, and the cluster is configured to say which claims to use. Some clusters add a prefix to these names to avoid clashes, so the name in a binding may look slightly different from the name a person uses to log in.

Whenever a binding does not seem to work, confirm the exact name that the cluster sees. The whoami-style features of modern tools, or the authentication review feature of the API, can show the identity that your requests carry. Fixing a mismatch of one character is often all that is needed.

Because every pod has an identity, service accounts are where many real-world RBAC mistakes occur.

The Default Service Account

Every namespace has a service account called default. A pod that does not name another account uses it. If someone grants permissions to the default account, every pod in that namespace that relies on it inherits those permissions, including pods that never needed them. This is a classic source of accidental over-privilege.

One Account Per Application

A better approach is to create a dedicated service account for each application that needs to talk to the API, grant it exactly the permissions required, and name it in the pod’s settings. Applications that never talk to the API server can be given no permissions at all, and it is wise to prevent their pods from receiving an API token in the first place.

How Pods Prove Their Identity

Modern clusters give pods short-lived tokens that are bound to the pod, rotate automatically, and expire when the pod ends. Older approaches created long-lived tokens stored as secrets, which stay valid until deleted and are more dangerous if leaked. Prefer the short-lived form wherever your cluster version supports it.

Preventing Unnecessary Token Exposure

Many applications never call the API server, yet by default their pods receive a service account token mounted in the container. If such an application is compromised, the attacker finds a token waiting for them. Turning off automatic token mounting for these pods removes that opportunity at no cost to the application. It is a simple setting that closes a real gap, and it is worth making the default in your namespaces.

For applications that do need the API, prefer tokens with a limited lifetime and a specific audience. Short lifetimes mean that a stolen token stops working soon, and narrow audiences mean that it cannot be replayed against other services. These small choices add up to substantial protection.

Every cluster starts with ready-made ClusterRoles that cover the most common needs.

The Four User-Facing Roles

System Roles

Besides these four, the cluster ships many roles whose names begin with a system prefix. They are used by the cluster’s own components, such as the scheduler and the node agents, and should not be edited or removed. Cluster upgrades restore them to their original definitions, so any changes you make to them are lost.

Using the Default Roles as a Starting Point

The default roles are not only convenient but also a good teaching aid. Reading their definitions shows how the Kubernetes authors think about grouping permissions. For example, the view role deliberately excludes secrets, because reading secrets is more sensitive than reading most objects. The edit role excludes roles and bindings, because managing access is a separate responsibility from managing workloads. These choices are worth copying when you write your own roles.

When none of the defaults fits, start from the nearest one and adjust. If a team needs edit, but without the ability to read secrets, write a custom role that lists the desired objects explicitly. Do not modify the defaults themselves, since the cluster restores them, and your changes would be lost or, worse, silently reset in the middle of an incident.

Aggregation lets one ClusterRole automatically collect the rules of other ClusterRoles that carry a matching label.

How Aggregation Works

An aggregated ClusterRole contains a selector instead of its own rules. Any ClusterRole in the cluster that has a label matching the selector has its rules added to the aggregated role automatically. A controller in the cluster keeps the combined list up to date. When a new ClusterRole with the right label appears, the aggregated role grows without anyone editing it.

Why It Exists

Aggregation solves an extension problem. When you install a new kind of object, such as a custom resource added by a database operator, the built-in view, edit, and admin roles know nothing about it. The operator can ship a small ClusterRole with the matching label, and the built-in roles automatically gain the ability to view or edit the new kind. Teams keep using the same familiar roles, and they cover the new objects.

flowchart LR
    C1[Small role: view custom database objects] --> AGG[Aggregated view role]
    C2[Small role: view custom certificate objects] --> AGG
    C3[Built-in view rules] --> AGG
    AGG --> SUB[Everyone bound to view now sees all three]
        

Aggregation Compared With Copying

Some teams avoid aggregation and instead copy rules from one role into another by hand. This works until the source changes, at which point the copy silently becomes out of date. Aggregation keeps the connection live, so updates flow automatically. The trade-off is that this automation also spreads mistakes automatically, which is why review of labelled roles matters.

If your cluster has few extensions and your roles rarely change, copying may be simple enough. If you install many operators and want consistent coverage by the built-in roles, aggregation saves ongoing effort and prevents the gaps that manual copying leaves.

Rules can be made finer than a whole resource kind, which is how you achieve truly narrow permissions.

Subresources

Some resources have parts that are addressed separately. A pod has a log part, an execution part for running commands inside containers, and a status part. Each of these is a subresource, and permissions are granted on them separately from the parent. Permission to get pods does not include permission to read their logs. Permission to run commands inside a container needs its own explicit grant, and it is one of the most powerful things you can hand out.

Resource Names

A rule may name specific objects, so that it applies only to those and not to every object of the kind. For example, a rule can allow getting and updating one config map with a particular name, and no others. This is ideal for programs that manage exactly one object. There are limits: a name restriction cannot be used with list, watch, or create in the usual way, because the request does not name a single existing object.

Non-Resource URLs

The API server also offers addresses that are not objects, such as health checks and version information. ClusterRoles can grant access to them, and only ClusterRoles can, since they are not part of any namespace.

Combining Fine-Grained Rules Wisely

Fine-grained rules give precision but also add complexity. A role that lists twenty resource names, five subresources, and a dozen verbs is precise but hard to maintain. When a new object is added, someone must remember to update the role. Balance precision against upkeep, and reserve the finest controls for the most sensitive objects, such as a specific secret or a critical config map.

For the rest, resource-level rules with a narrow list of verbs usually strike the right balance. The goal is a design that people can understand and maintain, because a design that nobody understands will be widened carelessly at the first inconvenience.

RBAC only adds permissions. It never subtracts them, and understanding this explains many surprises.

Allow Only, No Deny

Unlike some systems, RBAC has no deny rule. Every request starts as forbidden. Each role a subject holds may add allowances, and the request is permitted if at least one rule from any of the subject’s bindings allows it. There is no way to say that a subject may do everything in a role except one action. If you want to exclude something, you must not grant it in the first place.

flowchart TD
    Q[Request: who, verb, resource, namespace] --> B[Collect all bindings that match the subject]
    B --> R[Gather rules from every bound role]
    R --> M{Does any rule allow this request?}
    M -- Yes --> OK[Allowed]
    M -- No --> NO[Forbidden]
        

Why This Matters in Practice

Because permissions add up, a subject with two small roles has the sum of both. A person in three groups holds the union of all the groups’ roles. This is why a single overly generous binding can undo a whole careful design. When someone has more access than expected, the cause is nearly always one extra binding, often through a group they belong to or a wide default binding.

Evaluation Order and Other Authorizers

A cluster may also use other authorization methods in addition to RBAC. They are consulted in a set order, and the first to allow the request wins. If none allows it, the request is refused. In most clusters RBAC is the main method, but it is worth checking your cluster’s configuration when access behaves in unexpected ways.

Common Surprises From the Additive Model

Three surprises appear again and again. First, a person receives more access than expected because they belong to several groups, each with a modest role that together add up to a lot. Second, a narrow custom role has no effect because a broad default role is also bound. Third, removing a binding seems to change nothing because another binding grants the same access by a different route. In all three cases, the solution is to list every binding that touches the subject and add up their permissions.

Building a habit of drawing the full picture, rather than looking at one binding at a time, prevents most of these surprises. Tools that render an identity’s effective permissions are especially helpful here, since they do the adding for you.

Kubernetes has built-in protection against people granting themselves or others more power than they hold.

You Cannot Give What You Do Not Have

To create or update a role, a person must already hold every permission that the role contains, or else hold a special permission called escalate on roles. To create a binding, a person must already hold all the permissions in the referenced role, or hold a special permission called bind on that role. These two checks prevent a low-privileged person who can edit RBAC objects from promoting themselves to administrator.

Delegation Done Safely

Teams often want to let namespace owners manage access for their own teams. The safe way is to give them the admin role in their namespace, which already allows them to manage roles and bindings there, and to rely on the holding rule to keep them within their own power. Avoid handing out escalate or bind to delegate, because these bypass the safety net completely.

Impersonation as a Related Power

Kubernetes also has a permission called impersonate, which lets a subject send requests as if it were another user, group, or service account. It is useful for administrators who want to test what a role can do, and for gateways that forward requests on behalf of users. It is also dangerous, because the holder can act as anyone they are permitted to impersonate, including highly privileged identities.

Treat impersonation like escalation. Grant it to as few subjects as possible, limit it to specific named identities, and record its use in the audit log. A well-designed cluster gives impersonation to administrators for testing and to a few trusted gateways, and to nobody else.

Some permissions look harmless but quietly give the holder far more power than their names suggest.

The Indirect Path

The most surprising item is the ability to create pods. It seems to be an ordinary developer permission, yet a pod can be told to run with any service account in its namespace. Anyone who can create a pod there can therefore borrow the permissions of the strongest service account in that namespace. The lesson is that permissions must be judged by what they can lead to, not only by what they say.

Guarding Secrets Beyond RBAC

Since secrets are among the most sensitive objects, protect them in more than one way. Use RBAC to limit who can read them, encrypt them at rest in the cluster database, and consider external secret systems that keep the values outside the cluster and deliver them only to the pods that need them. Each layer covers a failure of the others.

Also remember that reading secrets is not only about the secret objects. Anyone who can read the logs of a pod that prints its secrets, or run commands in a pod that has them mounted, can reach the same values by another road. A complete review follows every road, not only the obvious one.

You should never guess about permissions, because the cluster can answer directly.

Asking the Cluster

The standard command line tool includes a can-i command. It asks the cluster whether the current identity may perform a given verb on a given resource, and the answer is a plain yes or no. With an option to impersonate, an administrator can ask the same question on behalf of another user, group, or service account, which is the best way to test a new role before handing it out. Listing all the permissions of an identity in a namespace is also possible.

Finding Out Who Holds a Permission

The reverse question, who can do this, is harder. The core tool does not answer it directly, but community add-ons do by reading all roles and bindings. Asking who can read secrets, or who can create pods, is a very valuable exercise, and many teams run it as a regular check.

Making Tests Part of Your Process

Permission tests are most valuable when they run automatically. A team can keep a list of expected yes and no results for each important identity and run it whenever roles or bindings change. If a change accidentally widens access, a no result becomes a yes and the test fails, alerting the team before the change reaches production.

This practice turns access design from a one-time effort into a living safety net. It also documents the intent: the list of tests states, in plain terms, what each subject is supposed to be able to do. New team members learn the design quickly by reading it.

Good design starts from what people and programs actually need and grants nothing more.

The Least Privilege Idea

Least privilege means that each subject holds only the permissions required for its task. It limits the damage of mistakes, stolen credentials, and compromised applications. It is easy to say and takes discipline to practice, because granting too much is always faster than working out exactly what is needed.

Practical Patterns

Balancing Convenience and Safety

Least privilege has a cost in convenience. Narrow roles mean that people occasionally hit a Forbidden error and must ask for more. Teams that make the request process quick and friendly find that people accept the narrowness willingly. Teams that make it slow and bureaucratic find that people ask for broad access up front, defeating the purpose. The process around the roles matters as much as the roles themselves.

A useful compromise is to allow broad read access, since reading is mostly harmless in namespaces without secrets exposure, and to keep write access narrow and specific. Another is to provide self-service creation of namespaces for teams, with standard bindings applied automatically, so that people start with sensible access without waiting.

When a request is refused, the error message itself tells you exactly which permission is missing.

Reading the Message

A Forbidden message names the identity, the verb, the resource, the API group, and the namespace. It reads almost like a sentence: this user cannot list pods in the API group core, in the namespace shop. Every part of that sentence corresponds to a field in a rule. Compare each part with the roles bound to the subject, and the gap usually stands out.

flowchart TD
    F[Forbidden error] --> ID{Is the identity what you expected?}
    ID -- No --> AU[Fix the login, token, or service account in use]
    ID -- Yes --> BD{Is there a binding for this identity or its groups?}
    BD -- No --> ADD[Create the binding]
    BD -- Yes --> NS{Is the binding in the right namespace?}
    NS -- No --> FIX1[Create it in the namespace of the request]
    NS -- Yes --> RL{Does the role list this verb, resource, and group?}
    RL -- No --> FIX2[Add the missing rule]
    RL -- Yes --> SB[Check subresources, names, and typing of subject names]
        

The Usual Suspects

Distinguishing RBAC Problems From Other Problems

Not every refusal comes from RBAC. An admission policy may reject a request even though RBAC allowed it, and the message will usually mention a webhook or a policy name rather than a permission. A network problem may look like an access problem when a request never reaches the API server at all. Learning to recognize these differences saves time.

Check the wording of the error. Messages that say a user cannot perform a verb on a resource are RBAC. Messages that mention a denied request by an admission webhook are policy. Messages about certificates, tokens, or unauthorized identity are authentication. Sending the investigation to the correct layer is half of the fix.

Granting permissions is only half the job, because you also need to see how they are used and how they change over time.

Audit Logs

The API server can record an audit log, a chronological list of requests showing who did what, to which object, when, and whether the request was allowed. This is the definitive evidence of how permissions are used. When something is deleted unexpectedly, the audit log names the identity that did it. When a role is changed, the audit log shows who changed it and what it looked like before and after. Without audit logs, investigations rely on memory and guesswork.

Audit policies control how much detail is captured. Recording every request in full detail produces enormous volumes, so teams usually record changes to sensitive objects, such as roles, bindings, and secrets, in more detail, and routine reads more briefly. Sending the logs to a separate, protected store ensures that an intruder cannot erase their own tracks.

Regular Access Reviews

Permissions drift. People change teams, projects end, and temporary grants become permanent through neglect. A regular review, perhaps every quarter, examines every binding that grants meaningful power and asks whether the holder still needs it. Reviews are much easier when bindings follow a naming convention and when groups, not individuals, are the usual subjects.

Turning Audit Logs Into Useful Alerts

Raw audit logs are too large to read, but a few simple alerts extract value. Alert when a ClusterRoleBinding is created, when a role gains new verbs, when the default service account receives permissions, and when a secret is read by an identity that does not usually read secrets. Each alert points to a change in the access picture that deserves a human look.

Start with a small number of alerts and refine them. If an alert fires too often on harmless activity, narrow it. If an incident reveals an activity that no alert caught, add one. Over time the alerts become a compact description of what your team considers unusual, and they keep watch when nobody is looking.

RBAC is powerful and well suited to Kubernetes, but it has costs that every team should understand.

Where RBAC Stops

RBAC decides whether a subject may perform an action on a kind of object. It cannot say that a deployment may only use images from a trusted registry, or that a pod may not run as the superuser. Those needs belong to admission control and policy tools, which examine the content of the request. A mature cluster combines RBAC with such tools, each covering what the other cannot.

Deciding How Much Structure You Need

A small cluster with one team may need only a handful of bindings, and elaborate designs would be a burden. A large shared cluster needs conventions, automation, and regular reviews. Match the amount of structure to the size and risk of your environment, and grow it as the cluster grows. Starting simple with sound habits, such as groups, namespaced grants, and dedicated service accounts, leaves room to add more later without rework.

Whatever the size, write down the rules of your design in a short page that new people can read. A design that lives only in the heads of a few experts fades as they change jobs, and the cluster gradually drifts into the tangle that RBAC was meant to prevent.

A short list of habits separates clusters that stay tidy and safe from clusters that become tangled and risky.

Habits Worth Building

Automating and Verifying Your RBAC Files

Once roles and bindings live in version control, you can check them automatically. Simple scripts can reject any role that uses wildcards, any binding to the default service account, and any new cluster-wide binding without a reviewer from the platform team. Community tools can also scan a live cluster and flag risky patterns, such as roles that allow reading all secrets or creating pods broadly.

Comparing the live cluster to the stored files at regular intervals catches manual changes. If someone creates a binding by hand during an incident and forgets to remove it, the comparison reveals it. Automation and comparison together keep the actual state of access aligned with the approved design.

RBAC appears in daily operations in some very recognizable situations.

Situations Where RBAC Decides the Outcome

A Gentle Adoption Roadmap

Measuring Progress

Simple measures show whether your access design is improving. Count the number of subjects bound to cluster-admin, the number of ClusterRoleBindings, the number of roles that use wildcards, and the number of workloads running as the default service account. Each of these should fall over time. Reporting them monthly keeps attention on the trend and makes success visible to everyone, including people who do not read roles for a living.

Short answers to the questions beginners ask most often about RBAC.

A Role lives in one namespace and can only grant access there. A ClusterRole is not tied to a namespace and can describe permissions on cluster-wide resources, or a reusable set of permissions that can be granted in one namespace or in all of them.

A role alone grants nothing. You must create a binding that attaches it to a subject, in the right namespace, with the subject name spelled exactly as the cluster sees it.

Yes. The permissions then apply only inside the namespace of the RoleBinding. This is the standard way to reuse a definition across many namespaces without granting cluster-wide access.

No. A ClusterRoleBinding can only reference a ClusterRole, because a namespaced role has no meaning across the whole cluster.

No. RBAC is purely additive. To keep someone from doing something, ensure that none of their bindings grants it. Other tools, such as admission policies, can add restrictions that RBAC cannot express.

From outside the cluster. Kubernetes has no user objects. It trusts the identity shown by a certificate or by a token from an identity provider, and uses that name in bindings.

It is the identity of a program running in the cluster. Pods use it when talking to the API server, so its permissions should be as small as the program’s real needs.

Only a very small group who manage the cluster itself, and preferably through a controlled, logged, temporary process. Most people need view or edit within specific namespaces.

A pod can run as any service account in its namespace and can mount secrets there. Someone who can create pods can therefore borrow the permissions of stronger accounts in that namespace.

Use the can-i command with the option that impersonates the subject. Test the actions that should work and the actions that must not.

No. It controls access to the Kubernetes API only. Container security, network rules, and secret handling need other mechanisms.

It lets a ClusterRole automatically include the rules of other ClusterRoles that carry a matching label. It is how extensions can extend the built-in view, edit, and admin roles.

Role-based access control is how Kubernetes decides who may do what through its API. Roles and ClusterRoles describe permissions, while RoleBindings and ClusterRoleBindings grant them to users, groups, and service accounts. The pairing decides the reach: a Role with a RoleBinding stays within one namespace, a ClusterRole with a RoleBinding shares a definition but grants locally, and a ClusterRole with a ClusterRoleBinding applies everywhere.

Because permissions only add up, safe design means granting narrowly, preferring groups, using dedicated service accounts, avoiding wildcards, watching dangerous permissions, testing both yes and no cases, and reviewing regularly with the help of audit logs. Do this, and RBAC becomes a clear, explainable map of trust rather than a tangle of surprises.