🔐 Understanding RBAC in Kubernetes — A DevOps Engineer’s Guide

 As a DevOps engineer, managing user access in Kubernetes (K8s) is a critical task. Today, let’s talk about RBAC, which stands for Role-Based Access Control. It helps us control who can do what in a Kubernetes cluster.

🎯 Why RBAC is Important?

Let’s say your Dev team needs access to the cluster. But we don’t want to give them full admin access. For example, they might need permission to read and write deployments and services, but not delete or execute critical commands.

This is where RBAC comes into play.

Press enter or click to view image in full size

🧱 RBAC Basic Structure

RBAC in Kubernetes works just like AWS IAM:

• In AWS, you:
• Create a user
• Attach a policy (which defines what the user can do)
• In Kubernetes, you:
• Create a Role (defines permissions)
• Create a RoleBinding (assigns Role to a user or service account)

🔧 Step-by-Step: How RBAC Works

1. Role File (Defines Permissions)

The Role file defines:

• apiGroups — Defines the API version:
• apiGroups: ["apps"] # For Ingress use: ["networking.k8s.io"]
• resources — What resources the user can interact with:
• resources: ["deployments", "pods", "services"]
• verbs — What actions are allowed:
• verbs: ["get", "create", "update", "patch"]

🔄 Update vs Patch:

• update: Replaces the whole object (full update)
• patch: Only changes the specified fields (partial update)

2. RoleBinding File (Assigns the Role)

• Binds a Role to a User or Service Account
• Example section from RoleBinding:
• roleRef:
• kind: Role
• name: dev-role
• apiGroup: rbac.authorization.k8s.io
• To verify access:
• kubectl auth can-i create deployment -n <namespace> --as=<username>

🧪 This command checks: Can this user create a deployment in this namespace?

🧑‍💻 Users vs Service Accounts

In Kubernetes, two types of identities use resources:

1. User

• Typically external users (e.g., DevOps engineers or developers)
• In production, usually only admins are actual users.

2. Service Account

• Used by resources to talk to other resources.
• Example: A Deployment wants to communicate with a Service or Ingress.

📌 Think of it like this:

• Deployment → talks to → Service
• Ingress → talks to → Pods

To allow this communication securely, we use Service Accounts.

Example:

In production:

• We create service accounts like prd-sa, dev-sa
• Developers use the relevant one based on environment

To check permissions of a service account:

kubectl auth can-i delete deployment -n <namespace> --as=system:serviceaccount:<namespace>:<serviceaccount-name>

✅ Summary

• RBAC controls who can do what in Kubernetes
• Use Role to define permissions
• Use RoleBinding to assign roles to users or service accounts
• For internal resource communication, prefer Service Accounts
• Use kubectl auth can-i to check permission quickly

🎉 I hope this blog helps you understand the concept of RBAC in Kubernetes easily. If you found it useful, don’t forget to share it with your DevOps friends or team members!