DevOps Journey Week 16 – Mastering Kubernetes RBAC (Role-Based Access Control)

✨ Introduction

In my DevOps Week 16, I explored one of Kubernetes’ most important security features — RBAC (Role-Based Access Control).

RBAC defines what actions each user or service can perform inside your Kubernetes cluster.

---

🧠 Core RBAC Concepts

• Role → defines permissions for resources (e.g., pods, services)

• RoleBinding → connects roles to users or service accounts

• ServiceAccount → Kubernetes identity used by apps or users inside the cluster

• ClusterRole / ClusterRoleBinding → apply cluster-wide permissions

---

⚙️ My Practical Implementation

1. Create Developer ServiceAccount

kubectl create serviceaccount dev-user -n default

2. Create Read-Only Role

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

3. Bind Role to Developer

subjects:
- kind: ServiceAccount
  name: dev-user

4. Test Developer Permissions

kubectl auth can-i list pods --as=system:serviceaccount:default:dev-user -n default  # yes
kubectl auth can-i delete pods --as=system:serviceaccount:default:dev-user -n default # no

---

🔒 Security Understanding

• Each user or app has its own ServiceAccount and permissions.

• Admins can create or revoke roles anytime.

• Kubernetes API server ensures no user can access data beyond their permissions.

---

🚀 Key Takeaways

• RBAC is essential for Kubernetes security.

• Helps separate developer, tester, and admin access.

• Enables secure automation for CI/CD pipelines.

• Strengthens overall DevOps security posture.

---

🧭 Conclusion

After this hands-on exercise, I now understand how to implement and test RBAC in a real Kubernetes environment.
It’s a foundational concept for secure DevOps practices and cloud-native deployments.