PENALGO

Giao diện

Module 6: Mastering RBAC (Role-Based Access Control) ​

💡 HPN Engineering Philosophy

"Security is not an afterthought." Trong Kubernetes, mặc định là "Deny All". Bạn không có quyền làm gì cả cho đến khi được cấp phép cụ thể. Đây là nguyên tắc Least Privilege.

1. The Concept: AuthN vs AuthZ ​

Rất nhiều kỹ sư nhầm lẫn giữa hai khái niệm này. Hãy phân biệt rõ ràng:

Authentication (AuthN): "Who are you?" ​

  • Hệ thống hỏi: "Anh là ai? Có giấy tờ tùy thân (Passport/ID Card) không?"
  • Trong K8s: Được xử lý bởi Certificates (Client Certs), OIDC (Google/Okta), hoặc Service Account Tokens.
  • Kết quả: K8s biết bạn là user nguyen.van.a thuộc group developers.

Authorization (AuthZ): "What can you do?" ​

  • Hệ thống hỏi: "Anh nguyen.van.a được phép vào phòng Server không? Được phép xóa Database không?"
  • Trong K8s: Đây chính là RBAC (Role-Based Access Control).
  • Kết quả: Allow hoặc Deny.

IMPORTANT

AuthN xảy ra TRƯỚC AuthZ. Nếu bạn không chứng minh được danh tính, bạn thậm chí không đến được cửa kiểm soát quyền hạn.

2. The Four Pillars of RBAC ​

RBAC trong Kubernetes được xây dựng dựa trên 4 trụ cột chính. Hãy tưởng tượng đây là hệ thống cấp thẻ từ trong tòa nhà HPN Tower.

2.1. Role (Namespace Scope) ​

  • Định nghĩa: Một tập hợp các Rules (quy tắc) cho phép thực hiện hành động cụ thể trên các resources.
  • Phạm vi: Chỉ có tác dụng trong một Namespace cụ thể.
  • Ví dụ: "Thẻ nhân viên tầng 5" -> Chỉ mở được cửa ở tầng 5.
yaml
# role-developer.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: backend-team
  name: developer-role
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods", "services", "configmaps"]
  verbs: ["get", "list", "watch"] # Read-only access

2.2. ClusterRole (Cluster Scope) ​

  • Định nghĩa: Tương tự Role, nhưng phạm vi là toàn bộ Cluster.
  • Sử dụng cho:
    1. Cluster-scoped resources (Nodes, PV).
    2. Non-resource endpoints (/healthz).
    3. Áp dụng quyền giống nhau cho tất cả Namespaces.
  • Ví dụ: "Thẻ Admin tòa nhà" -> Mở được cửa ở mọi tầng, mọi phòng.
yaml
# clusterrole-monitor.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-monitor
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes"]
  verbs: ["get", "list", "watch"]

2.3. RoleBinding (The Grant) ​

  • Định nghĩa: Hành động trao Role cho một User (hoặc Group/ServiceAccount) trong một Namespace cụ thể.
  • Tính chất: User + Role = Permissions.
  • Ví dụ: Trao "Thẻ nhân viên tầng 5" cho nhân viên Alice.
yaml
# rolebinding-dev.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bind-dev-to-backend
  namespace: backend-team
subjects:
- kind: User
  name: alice@hpn.com # "Who"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer-role # "What Role"
  apiGroup: rbac.authorization.k8s.io

2.4. ClusterRoleBinding (The Super Grant) ​

  • Định nghĩa: Trao ClusterRole cho User trên phạm vi toàn bộ Cluster.
  • Cảnh báo: Rất nguy hiểm nếu dùng sai.
  • Ví dụ: Trao "Thẻ Admin tòa nhà" cho đội bảo trì hệ thống.

3. Visualizing RBAC Flow ​

Dưới đây là luồng xử lý quyền hạn trong Kubernetes:

4. HPN Standard: Least Privilege ​

Tại HPN, chúng ta tuân thủ nghiêm ngặt nguyên tắc Least Privilege (Quyền tối thiểu cần thiết).

❌ Anti-Pattern (Tuyệt đối cấm) ​

Không bao giờ gán cluster-admin cho Developer hoặc Application Service Account.

bash
# ĐỪNG BAO GIỜ LÀM THẾ NÀY CHO DEV
kubectl create clusterrolebinding bad-practice --clusterrole=cluster-admin --user=dev-junior

✅ Best Practice (HPN Standard) ​

Tạo custom Role chỉ cấp đúng quyền cần thiết.

Scenario: Developer cần debug ứng dụng trong namespace production. Solution: debug-role

  1. Được phép xem logs, exec vào pod.
  2. KHÔNG được phép xóa Deployment, Service hay sửa ConfigMap.
  3. KHÔNG được xem Secret.
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: debug-role
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"] # Exec yêu cầu verb 'create' trên subresource

5. Service Accounts: Identity for Bots ​

Pods không phải là User. Pods cần một "Identity" để nói chuyện với Kubernetes API Server. Đó là ServiceAccount.

  • Mọi Pod mặc định được mount default ServiceAccount (thường không có quyền gì).
  • Nếu App của bạn cần tương tác K8s API (ví dụ: Jenkins Agent, Prometheus), hãy tạo ServiceAccount riêng và Binding Role cho nó.

⚠️ Security Warning: Automount Token ​

Nếu ứng dụng của bạn không cần gọi K8s API (99% các web app thông thường), hãy tắt tính năng tự động mount token để giảm bề mặt tấn công. Hacker nếu chiếm được Pod sẽ không lấy được token để tấn công API Server.

yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: secure-app-sa
automountServiceAccountToken: false # <--- QUAN TRỌNG: Tắt mount token

6. Tổng kết ​

  1. AuthN != AuthZ: Biết bạn là ai khác với việc bạn được làm gì.
  2. Namespace Isolation: Ưu tiên dùng Role và RoleBinding. Hạn chế dùng ClusterRoleBinding.
  3. Least Privilege: Chỉ cấp quyền vừa đủ. "Review quyền là review code".
  4. Secure Bots: Tắt automountServiceAccountToken nếu không cần thiết.

CAUTION

Một cấu hình RBAC sai lầm có thể mở toang cánh cửa cho attacker chiếm quyền điều khiển toàn bộ cluster. Hãy cẩn trọng.

Professional Engineering Standards | © 2025 HPN Corporation