🧩 What I Learned This Week
This week in my DevOps journey, I implemented Kubernetes RBAC (Role-Based Access Control) — a critical mechanism for securing clusters and controlling user permissions.
⚙️ Hands-on Practice
Created a developer ServiceAccount
kubectl create serviceaccount dev-user -n default
Defined read-only permissions
kind: Role
metadata:
name: pod-reader
namespace: default
rules:
- apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"]
Bound the Role to the developer
kind: RoleBinding
metadata:
name: read-pods
subjects:
- kind: ServiceAccount name: dev-user roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io
Tested access
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
🔐 Why RBAC Matters in DevOps
Prevents unauthorized resource changes
Separates developer/tester/admin access
Enhances security compliance
Protects your Kubernetes workloads
🌱 Conclusion
RBAC is not just theory — it’s a real-world Kubernetes security control.
Through this week’s practice, I learned how to:
Create roles and bindings
Apply permissions to users
Validate actions using kubectl auth can-i
A must-learn for every DevOps engineer aiming for real-world Kubernetes expertise!
Top comments (0)