Kubernetes RBAC Explained: Roles, RoleBindings, and Secure Access Control
When organizations start using Kubernetes in production, security becomes one of the most important concerns.
Multiple teams interact with the same Kubernetes cluster:
Developers deploy applications
QA engineers verify deployments and analyze logs
DevOps engineers manage infrastructure
Platform administrators control cluster configuration
Without proper access control, any user or application could accidentally or maliciously modify critical resources.
For example:
A developer could accidentally delete production workloads
A QA engineer might remove resources from the
kube-systemnamespaceA malicious pod could access secrets or modify the API server
To prevent these situations, Kubernetes provides RBAC (Role-Based Access Control).
RBAC is the core security mechanism used to control access inside Kubernetes clusters.
What is Kubernetes RBAC?
RBAC stands for Role-Based Access Control.
It is a security model that regulates access to Kubernetes resources based on user roles.
Instead of giving everyone administrative access, RBAC allows administrators to define:
Who can access the cluster
What actions they can perform
Which resources they can interact with
This ensures that each user or application only has the permissions necessary to perform their tasks.
This approach follows a critical security principle:
Principle of Least Privilege
Users and applications should only receive the minimum permissions required to do their work.
Why RBAC is Simple — Yet Complicated
At first glance, RBAC appears simple.
The configuration mainly involves a few Kubernetes resources like:
Roles
RoleBindings
Service Accounts
However, RBAC becomes complicated when it is misconfigured.
Because RBAC directly impacts cluster security, mistakes can lead to:
Unauthorized access
Broken applications
Difficult debugging scenarios
Security vulnerabilities
Understanding the RBAC permission model is more important than focusing only on YAML syntax, because once the access model is clear, writing RBAC manifests becomes straightforward.
Two Major Areas of Kubernetes RBAC
RBAC in Kubernetes focuses on two main areas of access control.
1. User Management
User management refers to controlling access for human users interacting with the Kubernetes cluster.
In real organizations, different teams require different levels of access.
For example:
| Team | Access Requirement |
|---|---|
| Developers | Deploy applications and view logs |
| QA Engineers | Read application logs and resources |
| DevOps Engineers | Manage deployments and infrastructure |
| Administrators | Full cluster control |
RBAC ensures that each team receives only the permissions they need.
For example, a QA engineer should not have the ability to delete cluster components like etcd.
2. Service Account Management
RBAC also controls access for applications running inside the Kubernetes cluster.
Applications running in pods often need to interact with Kubernetes resources such as:
ConfigMaps
Secrets
API resources
For example:
An application might need to read a ConfigMap for configuration
A pod might need to retrieve secrets for database credentials
These permissions are handled using Service Accounts.
What Are Service Accounts?
A Service Account represents the identity of an application running inside Kubernetes.
It allows pods to interact securely with the Kubernetes API.
Service accounts are Kubernetes resources defined using YAML.
Example:
apiVersion: v1
kind: ServiceAccount
metadata:
name: app-service-account
If no ServiceAccount is explicitly specified, Kubernetes automatically assigns the default ServiceAccount from the pod’s namespace.
Kubernetes RBAC Architecture
RBAC works through three major components.
| Component | Purpose |
|---|---|
| User / ServiceAccount | Identity requesting access |
| Role / ClusterRole | Defines permissions |
| RoleBinding / ClusterRoleBinding | Grants permissions |
These three resources work together to control access.
A simplified RBAC workflow looks like this:
User / ServiceAccount
↓
RoleBinding
↓
Role
↓
Permissions
Roles and ClusterRoles
A Role defines what actions can be performed on Kubernetes resources.
Roles specify:
Which resources can be accessed
What operations are allowed
For example:
Read pods
List ConfigMaps
Access secrets
Role (Namespace Scope)
Roles apply within a specific namespace.
Example:
A developer may have permission to:
Read pods
Access ConfigMaps
View secrets
—but only within the development namespace.
ClusterRole (Cluster Scope)
ClusterRoles apply across the entire Kubernetes cluster.
They are typically used for:
Cluster administrators
Monitoring tools
System controllers
RoleBinding and ClusterRoleBinding
Creating a role alone does not grant any permissions.
Permissions are granted only when a RoleBinding connects a role to a user or service account.
RoleBinding
RoleBinding grants permissions within a specific namespace.
Example:
Developer Role
↓
RoleBinding
↓
Developer User
ClusterRoleBinding
ClusterRoleBinding grants permissions across the entire cluster.
Example:
Cluster Admin Role
↓
ClusterRoleBinding
↓
Administrator User
How Kubernetes Handles User Authentication
One important thing to understand is that Kubernetes does not manage users internally.
Unlike Linux systems where users can be created with commands like:
useradd developer
Kubernetes delegates user management to external identity providers.
Identity Providers Used in Kubernetes
Common identity providers include:
AWS IAM (for EKS clusters)
LDAP
Okta
Single Sign-On (SSO) systems
OpenID Connect (OIDC)
Identity brokers like Keycloak
For example:
In AWS EKS, Kubernetes integrates with IAM users and groups.
When a user logs in:
The identity provider authenticates the user
Kubernetes receives the identity information
RBAC rules determine the user's permissions
This approach enables centralized authentication and access control.
Kubernetes RBAC Demo Using Minikube
Now that we understand the RBAC concepts, let's perform a hands-on demonstration using Minikube.
This demo will show how to:
Create a namespace
Create a ServiceAccount
Define a Role
Bind the Role to the ServiceAccount using RoleBinding
Verify RBAC permissions
Step 1: Start the Minikube Cluster
First, start your local Kubernetes cluster using Minikube.
minikube start
Verify that the cluster is running.
kubectl get nodes
Example output:
NAME STATUS ROLES AGE VERSION
minikube Ready control-plane xxd v1.35.0
Step 2: Create a Namespace
Namespaces help logically isolate resources inside a Kubernetes cluster.
Create a namespace for the RBAC demo.
kubectl create namespace rbac-demo
Expected output:
namespace/rbac-demo created
Verify the namespace.
kubectl get namespaces
Example output:
NAME STATUS AGE
default Active xx
kube-system Active xx
kube-public Active xx
kube-node-lease Active xx
rbac-demo Active xx
Step 3: Create a ServiceAccount
A ServiceAccount represents the identity of applications running inside the cluster (for example pods).
Create a YAML file for the ServiceAccount.
vim serviceaccount.yaml
Add the following configuration:
apiVersion: v1
kind: ServiceAccount
metadata:
name: demo-service-account
namespace: rbac-demo
Save and exit the file.
Apply the configuration:
kubectl apply -f serviceaccount.yaml
Expected output:
serviceaccount/demo-service-account created
Verify the ServiceAccount:
kubectl get serviceaccounts -n rbac-demo
Example output:
NAME SECRETS AGE
default 1 xx
demo-service-account 1 xx
Step 4: Create a Role
Next, define a Role that allows read-only access to pods within the namespace.
Create the Role YAML file.
vim role.yaml
Add the following configuration:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: rbac-demo
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
Apply the Role.
kubectl apply -f role.yaml
Expected output:
role.rbac.authorization.k8s.io/pod-reader created
Verify the Role.
kubectl get roles -n rbac-demo
Example output:
NAME AGE
pod-reader xx
Step 5: Create a RoleBinding
Now we need to bind the Role to the ServiceAccount so that the ServiceAccount receives the defined permissions.
Create the RoleBinding YAML file.
vim rolebinding.yaml
Add the following configuration.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods-binding
namespace: rbac-demo
subjects:
- kind: ServiceAccount
name: demo-service-account
namespace: rbac-demo
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
Apply the RoleBinding.
kubectl apply -f rolebinding.yaml
Expected output:
rolebinding.rbac.authorization.k8s.io/read-pods-binding created
Verify the RoleBinding.
kubectl get rolebindings -n rbac-demo
Example output:
NAME ROLE AGE
read-pods-binding Role/pod-reader xx
Step 6: Verify RBAC Configuration
To inspect the permissions granted by the role, run:
kubectl describe role pod-reader -n rbac-demo
Example output (important section):
Rules:
Resources Verbs
pods get, list, watch
This means the role allows the following actions:
Get pods
List pods
Watch pods
inside the rbac-demo namespace.
Step 7: Verify RBAC Permissions Using kubectl auth can-i
Kubernetes provides a useful command to test RBAC permissions.
Check whether the ServiceAccount can read pods:
kubectl auth can-i get pods \
--as=system:serviceaccount:rbac-demo:demo-service-account \
-n rbac-demo
Expected output:
yes
Now test if the ServiceAccount can create pods.
kubectl auth can-i create pods \
--as=system:serviceaccount:rbac-demo:demo-service-account \
-n rbac-demo
Expected output:
no
This confirms that the ServiceAccount only has read-only access to pods.
Step 8: Optional Test – Create a Pod
Create a test pod inside the namespace.
kubectl run nginx --image=nginx -n rbac-demo
Verify the pod.
kubectl get pods -n rbac-demo
Example output:
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 xx
Important Note About Minikube Permissions
Even though the ServiceAccount only has read-only access, you can still create pods using kubectl.
This happens because Minikube grants your local kubectl user cluster-admin privileges by default.
You can verify this using:
kubectl auth can-i create pods
Example output:
yes
This means your current kubectl user has administrative permissions, which are separate from the ServiceAccount permissions.
The RBAC policy we created applies specifically to:
demo-service-account
not to your local kubectl user.
RBAC Workflow Explained
The RBAC configuration created in this demo works as follows:
ServiceAccount (demo-service-account)
│
▼
RoleBinding (read-pods-binding)
│
▼
Role (pod-reader)
ServiceAccount → represents the identity used by applications running inside the cluster
RoleBinding → connects the ServiceAccount to a Role
Role → defines the permissions allowed on Kubernetes resources
As a result, the demo-service-account now has permission to read pods within the rbac-demo namespace.
Summary
In this demo we performed the following steps:
Started a local Kubernetes cluster using Minikube
Created a namespace for RBAC testing
Created a ServiceAccount
Defined a Role with permissions to read pods
Created a RoleBinding to grant permissions to the ServiceAccount
Verified RBAC permissions using
kubectl auth can-i
This example demonstrates how Kubernetes RBAC controls which identities can access specific resources inside a cluster.