Lộ trình
Cloud Native Computing FoundationAssociateTuần 4: Tối ưu & vận hànhBài 27 / 30

Ngày 27: RBAC nâng cao

Thời lượng: 45 phút
Mục tiêu: 2 nhiệm vụ chính
Tiến độ lộ trình
ckangày 27
hoàn thành27 / 30 bài
Bối cảnh bài học

RBAC nâng cao bằng permission matrix: namespaced/cluster scope, Role/ClusterRole, RoleBinding/ClusterRoleBinding, aggregation và kiểm tra allow/deny thực tế.

đọc hiểuthực hànhcheckpoint
Bài giảng hôm nay

Học hiểu, rồi mới thực hành

RBAC nâng cao bằng permission matrix: namespaced/cluster scope, Role/ClusterRole, RoleBinding/ClusterRoleBinding, aggregation và kiểm tra allow/deny thực tế.

Bắt đầu đọc bài giảng

Nhiệm vụ bài học hôm nay

  • Thực hành tạo Role, ClusterRole phức tạp hơn
  • Luyện kiểm tra quyền bằng kubectl auth can-i
Instructor walkthrough

Bài giảng chi tiết: từ bài toán đến bằng chứng

Scenario xuyên suốt

Một ServiceAccount đọc được Pod nhưng không đọc Secret, hoặc chỉ cần xem một namespace lại được cấp quyền toàn cluster. Bài học dạy thiết kế quyền theo subject/resource/verb/scope, kiểm chứng cả positive và negative case rồi thu hồi an toàn.

01Đọc bài toán

Xác định actor, workload, constraint và trạng thái cuối cần đạt.

02Vẽ luồng / boundary

Chỉ ra request, dependency, identity và failure domain trước khi chọn công cụ.

03Chọn và thực hành

Thay đổi nhỏ nhất trong lab cô lập; command nào cũng phải nói rõ nó kiểm tra điều gì.

04Kiểm chứng / recovery

Đối chiếu trạng thái thực tế, tạo một failure variant và ghi cách hoàn tác.

Cách nối lý thuyết với thực tế
  • RBAC rule là tuple apiGroup/resource/subresource/verb/resourceNames/scope; `get pods` khác `get pods/log`, `list` khác `watch`, resource khác non-resource URL.
  • Role và RoleBinding namespaced; ClusterRole/ClusterRoleBinding cluster-scoped, nhưng ClusterRole có thể được bind namespaced để tái sử dụng rule trong một namespace.
  • ServiceAccount identity cần test bằng `--as=system:serviceaccount:NAMESPACE:NAME`; quyền của người chạy kubectl không đại diện cho Pod.
  • Aggregation labels có thể thêm rule vào aggregated ClusterRole; phải inspect effective rules, không chỉ đọc manifest Role riêng lẻ.

RBAC là permission matrix

Thiết kế từ câu hỏi: ai (user/group/ServiceAccount) được verb nào trên resource/subresource ở scope nào. Ví dụ đọc Pod không tự cho đọc pods/log hoặc Secret; RoleBinding namespaced không giống ClusterRoleBinding.

Verify effective permission

Dùng identity đầy đủ và test allow/deny: auth can-i get pods, get pods/log, list secrets, update deployments, --all-namespaces khi phù hợp. Inspect binding và effective ClusterRole/aggregation; không suy luận quyền chỉ từ tên role. Sau khi revoke, chạy lại negative test và ghi evidence.

Bài tập

Tạo hai ServiceAccount với quyền khác nhau, hoàn thiện matrix, triển khai bindings, chạy positive/negative tests, tạo một lỗi scope/subresource rồi debug. Pass khi quyền tối thiểu đúng và revoke/cleanup không ảnh hưởng system RBAC.

Terminal reference

Command list và cách dùng

Chạy từng lệnh theo đúng thứ tự. Trước các lệnh có thể tạo hoặc thay đổi tài nguyên, hãy kiểm tra profile, account và region.

Commands · read-only checkpoints
kubectl auth can-i --as=system:serviceaccount:cka-day27:reader get pods -n cka-day27
kubectl auth can-i --as=system:serviceaccount:cka-day27:reader get pods/log -n cka-day27
kubectl auth can-i --list --as=system:serviceaccount:cka-day27:reader -n cka-day27
kubectl get role,rolebinding,serviceaccount -n cka-day27 -o yaml
kubectl get clusterrole,clusterrolebinding -o yaml
kubectl describe rolebinding BINDING_NAME -n cka-day27
Hands-on lab

Thực hành theo scenario

  1. Tạo namespace `cka-day27`, ServiceAccount `reader` và `deployer`; viết permission matrix cho Pod get/list/watch, Pod logs, ConfigMap, Secret, Deployment update và non-resource `/healthz`.
  2. Tạo Role/ClusterRole và binding namespaced phù hợp; kiểm tra `auth can-i` ở cả allowed và denied cases, thêm `--all-namespaces` chỉ khi câu hỏi yêu cầu.
  3. Cố ý tạo binding scope sai hoặc thiếu subresource `pods/log`; đọc `kubectl auth can-i`, `get role*`, `get rolebinding*`, `get clusterrole*`, `describe` và audit/effective rules để sửa đúng object.
  4. Thử aggregation trong lab nếu cluster policy cho phép, quan sát effective ClusterRole; tạo variant đổi namespace/subject/resource/verb để phát hiện quyền vượt scope.
  5. Revoke binding thử nghiệm, xác nhận deny sau revoke, cleanup ServiceAccount/Role/binding theo owner; không đụng system:masters hoặc shared ClusterRole production.
Evidence checkpoint

Kiểm chứng kết quả

Không coi lệnh chạy thành công là đủ. Hãy đối chiếu output với trạng thái mong đợi:

  • Permission matrix đầy đủ subject/resource/verb/subresource/scope.
  • Role/ClusterRole và Binding scope được phân biệt đúng.
  • Positive/negative `auth can-i` có evidence cho ServiceAccount.
  • Aggregation/effective permission hoặc limitation được giải thích.
  • Revoke và cleanup chứng minh không còn quyền thừa.
Transfer to exam / production

Bẫy thường gặp và trade-off

CKA RBAC hay bẫy namespace và subresource. Luôn test identity đầy đủ, xem `pods/log` riêng, phân biệt RoleBinding với ClusterRoleBinding và chạy cả câu hỏi “can it not do?”.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: ServiceAccount cần đọc log của Pod trong một namespace nhưng không được đọc Secret. Thiết kế nào phù hợp nhất?

Kết thúc bài

Checklist trước khi sang Ngày 2