"Nếu bất kỳ ai cũng có thể xóa toàn bộ Pod hoặc Namespace trong Kubernetes, chuyện gì sẽ xảy ra?"

Nếu câu trả lời của bạn là "thảm họa", thì chúc mừng, bạn vừa hiểu lý do RBAC tồn tại.

---

Một tình huống rất thực tế

Hãy tưởng tượng công ty của bạn có một Kubernetes Cluster dùng chung.

Có nhiều nhóm cùng làm việc:

• 👨‍💻 Team Backend
• 🎨 Team Frontend
• 🧪 Team QA
• 🚀 Team DevOps

Một ngày đẹp trời, một lập trình viên chỉ muốn xem danh sách Pod:

kubectl get pods

Nhưng nếu người đó cũng có quyền chạy:

kubectl delete deployment payment

hoặc thậm chí:

kubectl delete namespace production

thì hậu quả sẽ rất nghiêm trọng.

Rõ ràng, không phải ai cũng nên có mọi quyền.

Đó chính là lúc RBAC xuất hiện.

---

1. RBAC là gì?

RBAC (Role-Based Access Control) là cơ chế phân quyền trong Kubernetes.

Nó trả lời một câu hỏi rất đơn giản:

Ai được phép làm gì trên tài nguyên nào?

Ví dụ:

• Backend chỉ được xem Pod.
• QA chỉ được xem Log.
• DevOps được deploy ứng dụng.
• Chỉ Admin mới được xóa Namespace.

---

2. RBAC hoạt động như thế nào?

RBAC gồm 3 thành phần chính:

User / ServiceAccount
          │
          ▼
       Role
          │
          ▼
    RoleBinding

Hay hiểu đơn giản:

Người dùng
      │
được gán
      ▼
Vai trò
      │
quy định
      ▼
Được phép làm gì

---

3. Role - Bộ quyền

Role là nơi định nghĩa quyền.

Ví dụ:

Có thể:
- get Pod
- list Pod
- watch Pod

Role này không cấp quyền, nó chỉ mô tả quyền.

Giống như viết một "chức danh":

"Nhân viên chỉ được xem dữ liệu."

---

4. RoleBinding - Gán quyền

RoleBinding dùng để gán Role cho một User hoặc ServiceAccount.

Ví dụ:

Developer
        │
RoleBinding
        │
        ▼
Read Pod

Lúc này Developer mới thực sự có quyền xem Pod.

---

5. ClusterRole là gì?

Role chỉ có hiệu lực trong một Namespace.

Nếu muốn áp dụng cho toàn bộ Cluster, Kubernetes dùng ClusterRole.

Ví dụ:

Có thể xem Node

Có thể xem Namespace

Có thể xem PV

Đây đều là các tài nguyên cấp Cluster.

---

6. ClusterRoleBinding

Tương tự RoleBinding nhưng áp dụng cho toàn Cluster.

Admin
      │
ClusterRoleBinding
      │
      ▼
Cluster Admin

Người này gần như có toàn quyền trên Kubernetes.

---

Ví dụ dễ hiểu

Giả sử bạn có 3 người:

Người	Quyền
Developer	Xem Pod
QA	Xem Log
DevOps	Deploy ứng dụng

Mỗi người đều có một Role khác nhau.

Nhờ vậy:

✅ Không ai vô tình xóa tài nguyên của người khác.

✅ Cluster an toàn hơn.

---

RBAC trong thực tế

Ở hầu hết doanh nghiệp:

• Developer không được xóa Namespace.
• QA không được sửa Deployment.
• DevOps có nhiều quyền hơn để vận hành hệ thống.
• Chỉ Admin mới có quyền cao nhất.

RBAC giúp mọi người chỉ có đúng những quyền cần thiết, không nhiều hơn.

Đây cũng là nguyên tắc bảo mật nổi tiếng:

Principle of Least Privilege (Nguyên tắc cấp quyền tối thiểu).

---

Tổng kết

RBAC không làm Kubernetes chạy nhanh hơn, cũng không giúp ứng dụng hoạt động ổn định hơn.

Nhưng nó giúp bảo vệ Cluster khỏi những thao tác nhầm hoặc truy cập trái phép bằng cách trả lời ba câu hỏi:

• Ai? (User hoặc ServiceAccount)
• Được làm gì? (Role hoặc ClusterRole)
• Được cấp quyền như thế nào? (RoleBinding hoặc ClusterRoleBinding)

Hiểu RBAC là bước quan trọng để bạn vận hành Kubernetes trong môi trường nhiều người cùng làm việc.

---

Bài tiếp theo

Đến đây, chúng ta đã biết ai được phép thao tác với Kubernetes.

Nhưng còn một câu hỏi khác:

Nếu các Pod đều có thể giao tiếp với nhau qua mạng, làm thế nào để ngăn một Pod truy cập trái phép vào Pod khác?

Chúng ta sẽ cùng tìm hiểu câu trả lời trong bài tiếp theo:

👉 Bài 23. NetworkPolicy – Firewall dành cho Pod.