# IAM trên GCP cho FDE: service account, role và cách lần ra lỗi 403 trong dự án của khách

> Phần lớn lỗi 403 trong dự án Google Cloud của khách không phải bug: nếu biết cách đọc, chúng thường chỉ ra danh tính nào đang thiếu quyền gì, và cả những lúc vấn đề nằm ngoài IAM.

Bản gốc: https://fdetimes.net/vi/bach-khoa/iam-gcp-service-account-loi-403-o-du-an-cua-khach/

Chín giờ sáng, bạn ngồi trong phòng họp của khách, terminal mở sẵn, chuẩn bị deploy job xử lý dữ liệu đầu tiên vào project Google Cloud của họ.

Lệnh chạy được vài giây rồi dừng lại với một dòng đỏ: `Caller is missing permission 'iam.serviceaccounts.actAs' on service account`. Người phụ trách hạ tầng bên khách quay sang hỏi: "Cần quyền gì thì nói, tôi cấp Editor cho anh luôn nhé?"

Cách bạn trả lời lúc đó cho khách thấy bạn có hiểu hệ thống của họ hay không. Nhận Editor thì hôm nay xong việc, nhưng bạn để lại một lỗ hổng trong production của khách. Còn nếu bạn chỉ ra đúng quyền đang thiếu, ở đúng chỗ, đội security của khách sẽ tin bạn trong những lần deploy sau.

Với FDE, IAM là kỹ năng dùng hằng tuần, vì bạn luôn làm việc trong môi trường của người khác: project của họ, org policy của họ, admin của họ. Bài này dạy cách đọc lỗi 403 như đọc một bản chẩn đoán.

## Mỗi lần deploy có hai danh tính, không phải một

Hiểu sai phổ biến nhất là nghĩ chỉ có "tôi" đang gọi API. Thực ra có hai danh tính. Một là bạn, người chạy lệnh deploy. Hai là service account, mà tài liệu của Google mô tả là loại tài khoản đặc biệt thường dùng cho ứng dụng hoặc workload, không dành cho con người. Job của bạn chạy dưới danh tính này.

Khi deploy, bạn yêu cầu Google gắn service account vào resource, ví dụ một Cloud Run function. Việc gắn đó cần quyền `iam.serviceaccounts.actAs`, nằm trong role Service Account User (`roles/iam.serviceAccountUser`). Google mô tả role này là quyền cho một principal gắn service account vào resource. Nó không cho tạo credential ngắn hạn; việc đó thuộc role Token Creator.

Vì thế, mỗi khi gặp 403, câu đầu tiên cần hỏi là danh tính nào đang bị từ chối.

**Điểm mấu chốt:** Mỗi lỗi 403 cần hai câu trả lời: ai đang gọi, và người đó thiếu quyền nào.

## Lần theo một ca từ đầu đến cuối

Thử hình dung một ca cụ thể. Khách giao cho bạn service account `job-runner` để chạy một Cloud Run function đọc dữ liệu BigQuery. Lệnh deploy báo lỗi actAs như trên.

Lỗi này nói rõ bạn, người deploy, thiếu quyền actAs trên `job-runner`. Tài liệu xử lý sự cố Cloud Run functions của Google đưa ra cách sửa cho đúng thông báo này: cấp Service Account User trên chính service account đó.

Chữ quan trọng ở đây là "trên chính service account đó". Bạn không cần quyền này ở cấp project. Lệnh gửi cho admin của khách nên hẹp như sau:

```bash
gcloud iam service-accounts add-iam-policy-binding \
  job-runner@CUSTOMER_PROJECT.iam.gserviceaccount.com \
  --member="user:fde@your-company.com" \
  --role="roles/iam.serviceAccountUser"
```

Deploy chạy được. Mười phút sau function lại báo 403, lần này khi đọc bảng BigQuery. Danh tính bị từ chối bây giờ là `job-runner`, không phải bạn. Cách sửa là cấp cho `job-runner` một predefined role vừa đủ để đọc dữ liệu cần thiết.

Theo Google, predefined role do Google tạo và duy trì, và quyền trong đó được cập nhật khi dịch vụ thay đổi. Như vậy cùng là 403 nhưng là hai bệnh khác nhau, chữa ở hai chỗ khác nhau.

## Vì sao không nhận luôn Editor?

Google viết rõ: trong production, đừng cấp basic role (Owner, Editor, Viewer) trừ khi không còn cách nào khác. Các role này phủ quá rộng.

Còn một cái bẫy ít người để ý: tùy cấu hình org policy, tài khoản mặc định mà Cloud Run dùng có thể đang mang role Editor trên cả project.

Nếu bạn không chỉ định service account, job của bạn có thể đang chạy với quyền Editor mà không ai hay.

Vì thế nên luôn tạo service account riêng cho từng workload và chỉ cấp đúng quyền nó cần. Khi predefined role vẫn còn rộng, bạn có thể dùng custom role, nhưng phải biết giới hạn của nó: custom role chỉ cấp được trong project hoặc tổ chức đã tạo ra nó.

Sang project thứ hai của cùng khách, bạn phải tạo lại. Vì vậy hãy giữ danh sách permission dưới dạng file trong repo thay vì nhớ trong đầu.

## Vừa cấp quyền mà vẫn 403: chờ hay sửa tiếp?

Đây là lúc nhiều kỹ sư sửa nhầm. Admin vừa cấp role, bạn chạy lại ngay và vẫn 403, rồi bắt đầu xin thêm quyền khác. Nhưng theo Google, thay đổi IAM là eventually consistent.

Sửa một policy thường mất 2 phút để có hiệu lực, có khi 7 phút hoặc lâu hơn. Nếu quyền được cấp bằng cách thêm bạn vào một group, độ trễ thường là vài phút nhưng có thể kéo dài hàng giờ.

Cách làm an toàn: hỏi admin cấp quyền qua policy hay qua group. Nếu qua group mà buổi deploy có hạn giờ, nên xin binding trực tiếp cho giai đoạn đầu và lên lịch chuyển sang group sau. Rồi chờ vài phút hẵng kết luận.

Nếu đã chờ đủ mà vẫn lỗi, hãy dùng Policy Troubleshooter. Công cụ này cho biết một principal có truy cập được resource hay không. Nhưng nó không chẩn đoán được lỗi do VPC Service Controls, nên nếu Troubleshooter báo "có quyền" mà request vẫn bị chặn, hãy hỏi khách về perimeter mạng của họ.

## Khi lỗi đến từ org policy của khách

Có những lỗi mà quyền IAM của bạn không sửa được. Bạn muốn tạo key JSON cho service account để test từ laptop và nhận dòng `Key creation is not allowed`. Đó là org policy của khách đang chặn việc tạo key.

Google coi service account key là rủi ro bảo mật nếu không được quản lý đúng cách, nên nhiều tổ chức tắt hẳn tính năng này. Đừng xin ngoại lệ. Thay vào đó, hãy hỏi thẳng admin của khách: "Nếu không dùng key, bên anh cho phép tôi chạy và test code dưới danh tính service account này bằng cách nào?"

Tương tự, org policy có thể cấm gắn service account của project này vào resource ở project khác. Nếu kiến trúc của bạn để job ở project A dùng service account từ project B, bạn sẽ gặp 403 dù mọi role đã đúng. Cách sửa là đặt service account cùng project với workload, không phải xin thêm quyền.

## Những lỗi hay gặp

Lỗi đầu tiên là cấp quyền cho sai danh tính: thêm role cho chính bạn trong khi người thiếu quyền là service account runtime, hoặc ngược lại. Lỗi thứ hai là để job chạy bằng tài khoản mặc định. Lỗi thứ ba là xin thêm quyền khi vấn đề thật là độ trễ lan truyền hoặc org policy.

Kỹ năng này đáng có một dòng riêng trong CV, chẳng hạn: "deploy vào project GCP của khách với service account riêng, quyền tối thiểu, làm việc cùng đội security".

Khi JD FDE nhắc đến "customer cloud environments" hay "security reviews", hãy chuẩn bị sẵn cho phỏng vấn một ca 403 kể được rành mạch, từ lúc thấy lỗi đến lúc sửa xong. Một câu chuyện như vậy cho người phỏng vấn thấy cách bạn làm việc trong môi trường của khách.

Lần tới có người đề nghị "cấp Editor cho nhanh", hãy đưa họ một lệnh binding trên đúng một service account. Deploy vẫn xong, và production của khách không phải gánh thêm quyền thừa.

**Thử ngay tuần này:**

- Trong một project thử, tạo service account riêng cho một Cloud Run function, cố ý deploy khi chưa có Service Account User để gặp lỗi actAs, rồi sửa bằng binding trên đúng service account đó.
- Viết một trang 'danh sách quyền cần có' cho dự án hiện tại: mỗi danh tính, mỗi role, ở phạm vi nào, và gửi cho admin IAM của khách trước buổi deploy.
- Dùng Policy Troubleshooter để kiểm tra một permission của service account runtime trước khi chạy job thật.

## Nguồn

- [Service accounts overview | Identity and Access Management (IAM) | Google Cloud Documentation](https://docs.cloud.google.com/iam/docs/service-account-overview)

- [Roles for service account authentication | Google Cloud Documentation](https://docs.cloud.google.com/iam/docs/service-account-permissions)

- [Troubleshoot Cloud Run functions | Google Cloud Documentation](https://docs.cloud.google.com/functions/docs/support)

- [Roles overview | Identity and Access Management (IAM) | Google Cloud Documentation](https://docs.cloud.google.com/iam/docs/roles-overview)

- [Access change propagation | Identity and Access Management (IAM) | Google Cloud Documentation](https://docs.cloud.google.com/iam/docs/access-change-propagation)

- [Troubleshoot IAM permissions | Policy Intelligence | Google Cloud Documentation](https://docs.cloud.google.com/iam/docs/troubleshooting-access)

- [Restrict IAM service account usage | Google Cloud Documentation](https://docs.cloud.google.com/resource-manager/docs/organization-policy/restricting-service-accounts)

- [How to Configure Cloud Run to Use a Custom Service Account with Least-Privilege Permissions](https://oneuptime.com/blog/post/2026-02-17-how-to-configure-cloud-run-to-use-a-custom-service-account-with-least-privilege-permissions/markdown)