Lộ trình
Cloud Native Computing FoundationAssociateTuần 2: Đào sâu dịch vụ cốt lõiBài 13 / 30

Ngày 13: Job & CronJob

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

Thiết kế Kubernetes RBAC với Role/ClusterRole, bindings, ServiceAccount và impersonation; test quyền tối thiểu thay vì cấp cluster-admin.

đọ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

Thiết kế Kubernetes RBAC với Role/ClusterRole, bindings, ServiceAccount và impersonation; test quyền tối thiểu thay vì cấp cluster-admin.

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

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

  • Thực hành tạo Job chạy 1 lần và CronJob định kỳ
  • Học cách xử lý Job thất bạ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 Pod cần đọc ConfigMap trong namespace nhưng được gán cluster-admin; developer chỉ cần xem Pod nhưng lại có quyền delete Secret. Bài học xây permission matrix và kiểm chứng allow/deny theo scope.

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ế
  • Role namespaced; ClusterRole có thể mô tả cluster-scoped hoặc dùng trong namespace binding; binding quyết định subject và scope thực tế.
  • ServiceAccount là workload identity trong Kubernetes; RBAC Kubernetes khác cloud IAM và khác secret credential.
  • Rules gồm apiGroups/resources/verbs/resourceNames; `get/list/watch` khác `create/update/patch/delete`, subresource như logs/exec có scope riêng.
  • RoleBinding trong namespace cấp quyền Role/ClusterRole trong namespace; ClusterRoleBinding cấp cluster-wide và có blast radius lớn.

RBAC là permission graph

Đọc subject → binding → role → apiGroup/resource/verb → scope. Role/RoleBinding thường giới hạn namespace; ClusterRole/ClusterRoleBinding có thể mở rộng rất lớn. ServiceAccount là identity của workload, không phải lý do để nhúng token vào image.

Verify effective access

Dùng auth can-i để test allowed/denied path, kể cả namespace và subresource. Một Role tên “reader” vẫn có thể sai nếu verb/resource quá rộng. Sau thay đổi, inspect binding và test lại; cleanup phải revoke binding trước khi xóa identity.

Bài tập

Tạo reader Role/Binding, test ConfigMap allow và Secret/delete deny, sau đó mô phỏng revoke. Ghi permission matrix, expected can-i output và cleanup. Pass khi không cần cluster-admin để hoàn thành task.

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 --list --as=system:serviceaccount:cka-day13:reader -n cka-day13
kubectl auth can-i get configmaps --as=system:serviceaccount:cka-day13:reader -n cka-day13
kubectl auth can-i delete secrets --as=system:serviceaccount:cka-day13:reader -n cka-day13
kubectl get role,rolebinding,serviceaccount -n cka-day13 -o yaml
Hands-on lab

Thực hành theo scenario

  1. Tạo namespace `cka-day13`, ServiceAccount `reader`, Role chỉ get/list/watch ConfigMap và RoleBinding; không dùng cluster-admin.
  2. Dùng `kubectl auth can-i` với `--as=system:serviceaccount:...` để test allow/deny, namespace scope và cluster-scoped resource.
  3. Cố ý test binding rộng trong lab, inspect role/binding subjects/rules, thu hồi và verify quyền đã mất; không impersonate production.
  4. Cleanup Role/Binding/ServiceAccount namespace; kiểm tra không còn ClusterRoleBinding test hoặc secret token artifacts.
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:

  • Role/ClusterRole/Binding scope phân biệt đúng.
  • ServiceAccount subject và rule verbs/resources có rationale.
  • Can-i allow/deny evidence đầy đủ.
  • Không cấp cluster-admin/ClusterRoleBinding thừa.
  • Revoke/cleanup RBAC có proof.
Transfer to exam / production

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

CKA RBAC cần đọc verb/resource/apiGroup và namespace scope. `kubectl auth can-i` là cách kiểm tra effective permission; đừng suy luận từ tên Role.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Pod trong namespace cần đọc ConfigMap cùng namespace nhưng không cần xóa Secret. Thiết kế phù hợp nhất là gì?

Kết thúc bài

Checklist trước khi sang Ngày 2