DevOps Week 16: Kubernetes RBAC Hands-On β€” Securing Cluster Access


🧩 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!



Source link