ServiceAccount và gán quyền cho workload

Bài trước ta đã dựng xong Role, ClusterRole và các binding. Câu hỏi còn treo lại là: khi một pod gọi API server thì nó là "ai"? Câu trả lời là ServiceAccount. Đây là dạng bài rất hay xuất hiện trong CKA, thường chỉ 3 đến 5 phút nhưng dễ mất điểm vì quên namespace hoặc gán quyền quá rộng.

flowchart LR
    Pod["📦<br/>Pod"] --> SA["🪪<br/>ServiceAccount"]
    SA --> Token["🔑<br/>Token mount"]
    Token --> API["🖥️<br/>API server"]
    API --> RBAC["🔐<br/>RoleBinding"]

Mục tiêu bài học

• Giải thích được ServiceAccount là identity namespaced của workload khi gọi API server.
• Tạo ServiceAccount và gắn vào Pod hoặc Deployment bằng spec.serviceAccountName.
• Cấp quyền tối thiểu cho ServiceAccount bằng Role hoặc ClusterRole kết hợp RoleBinding.
• Kiểm chứng quyền bằng kubectl auth can-i --as và bằng token thật trong pod.
• Nhận diện các lỗi khiến SA "có quyền mà vẫn 403".

Ôn lại nhanh

Bốn dòng của bài RBAC vẫn đúng: subjects là ai, roleRef là quyền gì, Role thì namespaced còn ClusterRole thì không, và RoleBinding chỉ có hiệu lực trong namespace chứa nó. Bài này chỉ thay "ai" từ user/group sang ServiceAccount.

Ví dụ làm mẫu

Đề bài kiểu thi: trong namespace dev, tạo ServiceAccount api-reader, cấp quyền chỉ get và list pods, gắn vào Deployment web, sau đó chứng minh pod đọc được danh sách pod.

1. Tạo namespace `dev` và ServiceAccount `api-reader`.
2. Tạo Role `pod-reader` cho phép `get`, `list` trên `pods`.
3. Tạo RoleBinding `pod-reader-binding` nối Role với ServiceAccount.
4. Gắn `serviceAccountName: api-reader` vào pod template của Deployment.
5. Kiểm chứng bằng `kubectl auth can-i --as` và bằng token trong pod.

Bước 1, tạo tài nguyên nền:

kubectl create namespace dev
kubectl create serviceaccount api-reader -n dev

Bước 2, Role chỉ đúng những verb cần thiết:

This lesson is part of the paid section. Sign in and purchase the course to view the full content. Sign in