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

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.

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:

gcloud iam service-accounts add-iam-policy-binding \
  job-runner@CUSTOMER_PROJECT.iam.gserviceaccount.com \
  --member="user:[email protected]" \
  --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.