Kubernetes RBAC Demystified: ServiceAccount, Role, RoleBinding, ClusterRole & ClusterRoleBinding Explained with Real Examples

When developers start working with Kubernetes, one of the most confusing topics is RBAC (Role-Based Access Control).

Questions like these are very common:

• What is a ServiceAccount?
• Why do Pods need a ServiceAccount?
• What is the difference between Role and ClusterRole?
• When should I use RoleBinding vs ClusterRoleBinding?
• How are Namespaces related to RBAC?
• Can a ServiceAccount access another namespace?
• Why can’t I use a Role to access Nodes?

This article answers all of these questions using a real-world Asset Management Service example and builds the concepts step by step.

What is RBAC?

RBAC stands for Role-Based Access Control.

Its purpose is simple:

Control who can perform which action on which Kubernetes resource.

Whenever a Pod calls the Kubernetes API, Kubernetes asks two questions:

1. Who are you? (Authentication)
2. What are you allowed to do? (Authorization)

Understanding Namespace First

Before learning RBAC, you must understand Namespaces.

A Namespace is a logical boundary inside a Kubernetes cluster.

Think of it as a folder that groups related Kubernetes resources.

Example:

Kubernetes Cluster

├── dev │ ├── Pods │ ├── Secrets │ ├── ConfigMaps │ └── Services │ ├── test │ ├── Pods │ ├── Secrets │ └── ConfigMaps │ └── production ├── Pods ├── Secrets ├── ConfigMaps └── Services

Resources like

• Pods
• Deployments
• Services
• Secrets
• ConfigMaps
• ServiceAccounts
• Roles
• RoleBindings

are namespaced resources.

However, some resources belong to the entire cluster.

Examples:

• Nodes
• Namespaces
• StorageClasses
• PersistentVolumes
• CustomResourceDefinitions (CRDs)

These are called cluster-scoped resources.

This distinction is the foundation of RBAC.

Our Example

Suppose we have an Asset Management Platform.

production namespace

├── asset-service
├── inventory-service
├── notification-service
└── postgres

The Asset Service wants to read:

• Database Secret
• Application ConfigMap

How does Kubernetes decide whether it should allow this?

Let’s build the answer.

Step 1 — ServiceAccount (Identity)

Every Pod in Kubernetes runs as an identity.

That identity is called a ServiceAccount.

Example:

apiVersion: v1
kind: ServiceAccount
metadata:
 name: asset-sa
 namespace: production

Now configure the Deployment:

spec:
  serviceAccountName: asset-sa

Every Pod now runs as

system:serviceaccount:production:asset-sa

Think of a ServiceAccount as an employee ID card.

Without an identity, Kubernetes doesn’t know who is requesting access.

How Does a Pod Authenticate?

Many people think the ServiceAccount authenticates the Pod.

Not exactly.

When a Pod starts, Kubernetes automatically mounts a JWT token inside the Pod.

/var/run/secrets/kubernetes.io/serviceaccount/
token
namespace
ca.crt

Whenever the application calls the Kubernetes API, it automatically sends

Authorization: Bearer <JWT Token>

The API Server validates the token.

If valid, Kubernetes identifies the caller as

system:serviceaccount:production:asset-sa

Authentication is now complete.

Step 2 — Role (Permissions Within One Namespace)

Authentication only tells Kubernetes who the caller is.

Next comes authorization.

Suppose Asset Service needs

• Get Secret
• Get ConfigMap

inside the production namespace.

Create a Role.

kind: Role
metadata:
  name: asset-reader
  namespace: production
rules:
- apiGroups: [""]
  resources:
  - secrets
  - configmaps
  verbs:
  - get
  - list

A Role only defines permissions.

It does not assign them.

Step 3 — RoleBinding (Assigning Permissions)

A RoleBinding connects

• a Role
• to a ServiceAccount

Example:

kind: RoleBinding
metadata:
  namespace: production
subjects:
- kind: ServiceAccount
  name: asset-sa
roleRef:
  kind: Role
  name: asset-reader

Now the flow becomes

Pod
↓
ServiceAccount
↓
RoleBinding
↓
Role
↓
Allowed Permissions

Role Works Only Inside One Namespace

Suppose everything exists inside production.

production
Pod
↓
ServiceAccount
↓
RoleBinding
↓
Role
↓
Secret
ConfigMap

The Pod can read

production/db-password

It cannot read

dev/db-password

because a Role is limited to a single namespace.

This is the most common RBAC configuration used by applications.

Step 4 — ClusterRole

Now consider another application.

Prometheus.

Prometheus wants to monitor every namespace.

dev
test
production
qa

Creating the same Role repeatedly becomes difficult.

Instead we create

kind: ClusterRole
rules:
- apiGroups: [""]
  resources:
  - pods
  verbs:
  - get
  - list
  - watch

ClusterRoles are also mandatory for cluster-scoped resources.

For example,

kubectl get nodes

cannot be granted using a Role because Nodes are not inside any namespace.

Step 5 — ClusterRoleBinding

ClusterRole also only defines permissions.

To assign them,

create

ClusterRoleBinding

Flow

Pod
↓
ServiceAccount
↓
ClusterRoleBinding
↓
ClusterRole
↓
Permissions Across Cluster

The Most Common Confusion

Many people think

Role = same namespace

ClusterRole = different namespace

This is a good beginner’s rule but not the complete story.

The real rule is

• Role grants permissions within one namespace
• ClusterRole can grant permissions to
• cluster-scoped resources
• namespaced resources across multiple namespaces

Can a RoleBinding Reference a ServiceAccount from Another Namespace?

Yes.

Suppose Prometheus runs inside

monitoring

namespace.

monitoring
ServiceAccount
prometheus-sa

Now create a RoleBinding inside dev.

RoleBinding
Namespace = dev
↓
ServiceAccount
monitoring/prometheus-sa

This means

The ServiceAccount in monitoring receives the permissions of the Role defined in the dev namespace.

The ServiceAccount does not move.

Only its permissions apply inside dev.

This is an advanced RBAC concept that many Kubernetes users don’t know.

Why Then Use ClusterRole?

Suppose you have

200 namespaces

Using Roles means creating

• 200 Roles
• 200 RoleBindings

Instead

1 ClusterRole
+
1 ClusterRoleBinding

is much easier to manage.

Multiple ServiceAccounts in One Namespace

There is no rule saying one namespace should have only one ServiceAccount.

Example

production

asset-sa
inventory-sa
notification-sa
report-sa

Each application gets only the permissions it actually needs.

This follows the Principle of Least Privilege, one of the most important security practices in Kubernetes.

Can One Role Be Used by Multiple ServiceAccounts?

Yes.

Role
config-reader

can be assigned to

asset-sa
inventory-sa
notification-sa

using different RoleBindings.

Can One ServiceAccount Have Multiple Roles?

Yes.

asset-sa
↓
RoleBinding
↓
config-reader

and

asset-sa
↓
RoleBinding
↓
job-manager

The final permissions are the union of both Roles.

RBAC Rule Book

Whenever you’re confused, remember these rules.

Rule 1

Every Pod uses one ServiceAccount.

A ServiceAccount always belongs to one namespace.

Rule 2

A Role always belongs to one namespace.

It only grants permissions inside that namespace.

Rule 3

A RoleBinding always belongs to one namespace.

It binds a Role from the same namespace to one or more subjects.

The referenced ServiceAccount may belong to the same namespace or a different namespace.

Rule 4

A Role can only grant permissions to namespaced resources.

Examples:

• Pods
• Secrets
• ConfigMaps
• Deployments
• Services
• Jobs

A Role can never grant permissions for

• Nodes
• Namespaces
• StorageClasses
• PersistentVolumes

because these resources are cluster-scoped.

Rule 5

A ClusterRole has two superpowers.

Superpower 1

Grant access to cluster-scoped resources.

Examples:

• Nodes
• Namespaces
• StorageClasses
• PersistentVolumes

Superpower 2

Grant access to namespaced resources across multiple namespaces.

Examples:

• Pods
• Secrets
• ConfigMaps

Final Takeaways

• Every Pod runs using a ServiceAccount.
• ServiceAccounts provide identity.
• Kubernetes authenticates Pods using a ServiceAccount token.
• Roles grant permissions within one namespace.
• RoleBindings assign Roles to ServiceAccounts.
• ClusterRoles grant permissions to cluster-scoped resources or to namespaced resources across multiple namespaces.
• ClusterRoleBindings assign ClusterRoles to ServiceAccounts.
• A RoleBinding can reference a ServiceAccount from another namespace.
• The recommended practice is to follow the Principle of Least Privilege — grant every workload only the permissions it actually needs.

Conclusion

Kubernetes RBAC often appears complex because several objects work together. Once you separate identity (ServiceAccount), permissions (Role/ClusterRole), and assignment (RoleBinding/ClusterRoleBinding), the model becomes straightforward.

A practical mental model is:

• Identity → Who are you? → ServiceAccount
• Permissions → What are you allowed to do? → Role / ClusterRole
• Assignment → Who gets those permissions? → RoleBinding / ClusterRoleBinding
• Boundary → Where do those permissions apply? → Namespace or Cluster

Keeping these four concepts in mind will help you design secure, maintainable RBAC policies for real-world Kubernetes applications.