RBAC — ใครทำอะไรได้บ้าง
ควบคุมสิทธิ์ผู้ใช้และ Pod ด้วย Role/RoleBinding
พื้นฐานที่ควรรู้: ระบบความปลอดภัยที่ดีต้องมีการกำหนดว่า "ใคร" มีสิทธิ์ "ทำอะไร" บ้าง ไม่ใช่ทุกคนที่จะลบฐานข้อมูลได้ หรือไม่ใช่ทุกแอปที่จะมีสิทธิ์แก้ไขการตั้งค่าระบบ
RBAC เหมือนระบบบัตรพนักงาน — บัตรของแต่ละคนเปิดได้เฉพาะประตูที่ได้รับอนุญาต · Role = ชุดสิทธิ์ ("เปิดห้องเก็บของได้") · RoleBinding = การแจกบัตรนั้นให้คน/ทีม
RBAC (Role-Based Access Control) คุมว่าใคร (user, group, หรือ ServiceAccount ของ Pod) ทำ action อะไร (get/list/create/delete) กับ resource ไหนได้บ้าง — ยึดหลัก least privilege (ให้สิทธิ์น้อยที่สุดที่จำเป็น)
Role = ชุดสิทธิ์ · RoleBinding = แจกสิทธิ์ให้ subject
least privilege: ให้เท่าที่ต้องใช้จริง
- Role — สิทธิ์ภายใน namespace เดียว · ClusterRole — สิทธิ์ทั้งคลัสเตอร์
- RoleBinding — ผูก Role ให้ subject ใน namespace · ClusterRoleBinding — ผูกระดับคลัสเตอร์
- ServiceAccount — "ตัวตน" ที่ Pod ใช้เรียก API server (ทุก Pod มี ServiceAccount)
สรุป Key Takeaways
- RBAC คุม "ใครทำอะไรกับ resource ไหนได้" ยึดหลัก least privilege
- Role/RoleBinding = ระดับ namespace · ClusterRole/ClusterRoleBinding = ทั้งคลัสเตอร์
- ServiceAccount = ตัวตนของ Pod เวลาเรียก API — อย่าให้ cluster-admin พร่ำเพรื่อ
คำถามที่พบบ่อย
Role กับ ClusterRole ต่างกันยังไง
Role = สิทธิ์ใน namespace เดียว ส่วน ClusterRole = สิทธิ์ระดับทั้ง cluster (หรือใช้กับ resource ที่ไม่มี namespace เช่น node) — จับคู่ด้วย RoleBinding/ClusterRoleBinding — ทริคที่ใช้บ่อย: สร้าง ClusterRole กลางแล้วใช้ RoleBinding ผูกเข้าแต่ละ namespace เพื่อ reuse นิยามสิทธิ์
ServiceAccount คืออะไร ทำไม pod ต้องมี
ตัวตนของ "โปรแกรม" ใน cluster — pod ทุกตัวรันภายใต้ ServiceAccount (default ถ้าไม่ระบุ) เมื่อแอปต้องเรียก K8s API ให้สร้าง SA เฉพาะ + Role ที่สิทธิ์แคบที่สุด อย่าใช้ default SA ที่อาจถูกผูกสิทธิ์กว้างไว้ — หลัก least privilege เดียวกับ IAM
จะเช็คว่าตัวเอง (หรือ SA ไหน) มีสิทธิ์ทำอะไรได้ยังไง
kubectl auth can-i <verb> <resource> เช่น kubectl auth can-i delete pods -n prod และเติม --as system:serviceaccount:<ns>:<name> เพื่อเช็คแทน SA ตัวอื่น — เป็นคำสั่ง debug RBAC ที่เร็วที่สุด