# 🪪 ServiceAccount và gán quyền cho workload

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

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.

```mermaid
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.

```steps
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:

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

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