Lộ trình
Cloud Native Computing FoundationAssociateTuần 3: Kiến trúc & bảo mậtBài 20 / 30

Ngày 20: ServiceAccount

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

Cấp ServiceAccount riêng cho workload và Role/RoleBinding least privilege: identity mapping, automount token, positive/negative can-i và revoke evidence.

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

Cấp ServiceAccount riêng cho workload và Role/RoleBinding least privilege: identity mapping, automount token, positive/negative can-i và revoke evidence.

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

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

  • Thực hành tạo ServiceAccount riêng cho ứng dụng
  • Gán quyền tối thiểu bằng Role + RoleBinding
Instructor walkthrough

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

Scenario xuyên suốt

Pod dùng default ServiceAccount và vô tình có token/API access; hoặc Role đúng nhưng binding nhầm namespace/subject khiến app không làm được việc hoặc có quyền quá rộng. Bài học nối workload identity với RBAC policy và kiểm tra runtime.

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ế
  • ServiceAccount là identity namespaced của Pod; `serviceAccountName` chọn identity, không phải user đang chạy kubectl.
  • Role/RoleBinding namespaced; RoleBinding có thể bind ClusterRole nhưng scope quyền qua binding namespace cần hiểu rõ; tránh ClusterRoleBinding nếu không cần.
  • automountServiceAccountToken=false giảm credential exposure khi app không gọi API; nếu cần API, dùng token projection/audience/rotation policy phù hợp.
  • `kubectl auth can-i --as=system:serviceaccount:...` kiểm tra authorization nhưng phải test đúng resource/subresource/namespace và phân biệt operator quyền.

Workload identity và RBAC

Tạo identity riêng, ghi permission matrix, bind Role đúng namespace/subject rồi gắn serviceAccountName vào Pod. Operator quyền cao không đại diện cho workload; dùng auth can-i --as=system:serviceaccount:NS:SA và test cả allow/deny resource/subresource.

Token exposure

App không gọi Kubernetes API thì cân nhắc automountServiceAccountToken: false; nếu cần, giới hạn audience/scope/rotation theo platform policy. ServiceAccount token là credential, không log/commit. Revoke binding và chạy lại can-i là bằng chứng cleanup quyền.

Bài tập

Tạo reader/writer SA + Role/RoleBinding, triển khai Pod, verify identity/positive-negative permission, mô phỏng binding sai và sửa. Test automount, revoke, cleanup và lưu matrix không chứa token.

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 get serviceaccount,role,rolebinding -n ckad-day20 -o yaml
kubectl auth can-i get pods --as=system:serviceaccount:ckad-day20:reader -n ckad-day20
kubectl auth can-i get secrets --as=system:serviceaccount:ckad-day20:reader -n ckad-day20
kubectl auth can-i --list --as=system:serviceaccount:ckad-day20:reader -n ckad-day20
kubectl get pod POD_NAME -n ckad-day20 -o jsonpath="{.spec.serviceAccountName} {.spec.automountServiceAccountToken}{"\n"}"
kubectl get events -n ckad-day20 --sort-by=.lastTimestamp
Hands-on lab

Thực hành theo scenario

  1. Tạo namespace `ckad-day20`, ServiceAccount `reader`/`writer`, Role chỉ cho get/list/watch Pod hoặc update ConfigMap cần thiết và RoleBinding đúng subject; ghi matrix.
  2. Gắn `serviceAccountName` vào Pod/Deployment, đặt automount theo nhu cầu, verify Pod spec/SA token projection và identity bằng `kubectl auth can-i` positive/negative.
  3. Cố ý binding sai namespace/subject, thiếu subresource hoặc verb; đọc forbidden event/app log và Role/Binding YAML, sửa đúng scope rồi rollout/verify.
  4. Test variant đổi namespace, ServiceAccount, resource/verb và `automountServiceAccountToken`; chứng minh app không đọc Secret/cluster resource ngoài contract.
  5. Revoke binding, chạy lại can-i để thấy deny, cleanup workload/SA/Role/Binding/token artifacts; không in token hoặc sửa system:masters.
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:

  • Pod identity/ServiceAccount mapping có evidence.
  • Role/RoleBinding scope và permission matrix đúng.
  • Positive/negative can-i và subresource tests.
  • Automount/token exposure được quyết định theo nhu cầu.
  • Revoke/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

CKAD ServiceAccount task thường sai subject string hoặc namespace. Kiểm tra `serviceAccountName`, RoleBinding, rồi `auth can-i --as=system:serviceaccount:NS:SA`; test deny để chứng minh least privilege.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Ứng dụng chỉ cần đọc Pod trong namespace của nó và không cần gọi Kubernetes API trực tiếp. Thiết kế nào phù hợp?

Kết thúc bài

Checklist trước khi sang Ngày 2