Understanding Kubernetes RBAC

AshutoshM49 — Mon, 21 Apr 2025 17:37:14 +0000

What Is RBAC ?

RBAC stands for Role Base Access Control. It's How k8s decides who can do what and where in your cluster.

We will think like, We are going to a school. There will be teachers, We will be the students, and there will others, for example: Clerk, Head Masters and Many other people.

There are certain rules for every job in a school,
For example:

Teachers can take classes
Students can attend classes
Only the Principal can expel someone 👀

Just as a school has its own rules and regulations that everyone must follow, in Kubernetes, no user is above the system's governance. Role-Based Access Control (RBAC) allows us to define specific roles and permissions for users, dictating what actions they can perform within a cluster. For instance, a student's role might be limited to studying and listening to teachers, while a teacher's responsibility is to educate students. Similarly, in many organizational environments, teams, developers, and testers have distinct roles in application deployment and infrastructure management. To monitor application statistics, we assign specific roles to individuals or developers, granting them a defined set of permissions to perform actions within a Kubernetes cluster.

RBAC components

Roles/ClusterRoles
RoleBindings/ClusterRoleBindings

ClusterRole v/s Roles

The scope of role is within the namespaces
and the scope of clusterRole is in the entire cluster

FLOW OF KUBERNETES AUTHENTICATION

User and Service account -> KubeAPI -> Allow/Deny

Here a User/Service Account requests Kube API,
Kube API will check if it's authenticated, if any role or clusterRole is present, and if there is a binding role to the user.
then it will allow or deny

NOTE: in kubernetes, there are not any built in concepts of users. instead the authentication handled outside kubernetes typically via: x509, OpenID connect, StaticTokens etc

But we can proceed with a demo of creating a user by using a certificate.
We’ll use openssl to:

Create a private key
Generate a certificate signing request (CSR)
Sign it with the Kubernetes cluster CA
Create a kubeconfig for the new user

Step 1: Generate a private key

openssl genrsa -out <username>.key 2048

Step 2: Create a CSR

openssl req -new -key <username>.key -out <username>.csr -subj "/CN=<username>"

Step 3: Encode the CSR in base64 (no line breaks)

cat <username>.csr | base64 | tr -d '\n'

Copy the base64 output.
Step 4: Create a Kubernetes CertificateSigningRequestresource

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: <username>
spec:
  request: <paste-base64-output-here>
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 31536000  # Optional: 1 year (365 days)
  usages:
    - client auth

Save it as csr.yaml and apply:

kubectl apply -f csr.yaml

Step 5: Approve the CSR

kubectl certificate approve <username>

Once approved, fetch the signed certificate:

kubectl get csr <username> -o jsonpath='{.status.certificate}' | base64 --decode > <username>.crt

You now have:
.crt → Signed client certificate
.key → Private key

Step 6: Create a user entry in kubeconfig

kubectl config set-credentials <username> \
  --client-certificate=<username>.crt \
  --client-key=<username>.key

Step 7: Create a new context for your username
Replace with the actual cluster name from:

kubectl config get-clusters

After that

kubectl config set-context your-context \
  --cluster=<your-cluster-name> \
  --namespace=dev \
  --user=<username>

Then switch to this context:

kubectl config use-context youruser-context

At this point, the user is created and active, but has no permissions yet.

You need to switch back to kubernetes admin for continuing our demo for RBAC.
Step 1: Create a Role in the dev namespace
Here we created a role, which is applicable for "dev" namespace. and it will access pods to list and watch them. basically a readonly role.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

apply it.
Step 2: Create a RoleBinding for your user
Here we are creating a roleBinding to bind the role we created with the user.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: dev
subjects:
- kind: User
  name: <username> # this matches CN=username in cert
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader # this should be the role which is created to attach with the user. 
  apiGroup: rbac.authorization.k8s.io # it's like a category for a set of APIs in k8s (will read about GVK and GVR for learning more about these)

You will eventually try to run command in other namespaces it will give you a failure, and if you try to run the commands to see pods then it will work in the "dev" namespace.

Why RBAC Matters

🛡️ Security first: Least-privilege is the best policy.
👨‍💻 Multi-team clusters: Keeps teams in their lanes.
🧪 CI/CD pipelines: Our deployments can only do what they’re allowed to.

DEV Community: AshutoshM49

Understanding Kubernetes RBAC

What Is RBAC ?

RBAC components

ClusterRole v/s Roles

FLOW OF KUBERNETES AUTHENTICATION