Lộ trình
Google CloudAssociateTuần 4: Tối ưu & vận hànhBài 22 / 30

Ngày 22: IAM nâng cao

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

Thiết kế IAM nâng cao cho workload GCP bằng service account, impersonation, Workload Identity, least privilege, audit và credential lifecycle.

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

Thiết kế IAM nâng cao cho workload GCP bằng service account, impersonation, Workload Identity, least privilege, audit và credential lifecycle.

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

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

  • Học Service Account và cách gán quyền tối thiểu
  • Thực hành tạo Service Account cho ứng dụng
Instructor walkthrough

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

Scenario xuyên suốt

Một ứng dụng dùng service account key commit trong image và được cấp Editor toàn project vì team không hiểu principal, role và scope. Bài học thay credential dài hạn bằng identity có lifecycle và evidence kiểm tra được.

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ế
  • Service account là workload identity; user/group là human principal; quyền sử dụng/impersonate service account khác quyền mà service account có trên resource.
  • Predefined role + scope nhỏ nhất thường an toàn hơn Editor/Owner; custom role cần rationale, owner, version và review.
  • Attached service account, service account impersonation và Workload Identity Federation/Workload Identity có trust/lifecycle khác nhau.
  • Key JSON dài hạn tạo risk lưu trữ/rotation/revocation; ưu tiên short-lived credentials, metadata/identity platform và secretless design.

IAM workload theo chuỗi trust

Phân tách human → impersonate/actAs → service account → resource role. User có thể được phép chạy deployment nhưng workload không cần quyền của user; service account có quyền đọc bucket nhưng không nên có Editor project. Scope, inheritance và group membership quyết định effective access.

Credential lifecycle

Ưu tiên attached identity, Workload Identity hoặc impersonation với credential ngắn hạn. Nếu legacy key bắt buộc, phải có secret storage, rotation, monitoring và revoke date; không commit JSON vào repo/image/metadata. Audit log và deny test là evidence tốt hơn screenshot role.

Bài tập

Lập access matrix, thiết kế migration khỏi Editor/key, chạy read-only policy/role inspection và viết allow/deny/revoke evidence. Cleanup test binding/service account theo owner; không thao tác production.

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
gcloud iam service-accounts list --project=LAB_PROJECT_ID --format="table(email,displayName,disabled)"
gcloud projects get-iam-policy LAB_PROJECT_ID --format="yaml(bindings)"
gcloud iam service-accounts get-iam-policy SA_EMAIL --format="yaml(bindings)"
gcloud iam roles describe roles/storage.objectViewer --format="yaml(name,title,includedPermissions)"
Hands-on lab

Thực hành theo scenario

  1. Lập matrix principal → role → permission → scope → use case → expiry/owner: developer, deployer, VM/pod, auditor.
  2. Inspect service accounts, IAM policy, role definitions và audit context read-only; không tạo key hoặc cấp Owner cho lab.
  3. Thiết kế impersonation/Workload Identity flow: human được actAs đúng service account; workload chỉ có resource role cần thiết; test allow/deny path.
  4. Tạo revoke/rotation runbook và cleanup test bindings/service account; kiểm tra policy không còn binding rộng hoặc credential file trong artifact.
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:

  • Phân biệt human principal/workload identity/role/permission/actAs.
  • Role và scope là least privilege có rationale.
  • Không dùng long-lived service account key.
  • Có allow/deny evidence và audit/review date.
  • Revoke/rotation/cleanup có owner và rollback.
Transfer to exam / production

Bẫy thường gặp và trade-off

ACE hay đánh vào việc service account cần quyền trên resource khác với quyền user được impersonate nó. Đừng chữa AccessDenied bằng Owner hoặc key JSON.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: VM chỉ cần đọc object trong một bucket, nhưng service account đang có Editor project. Remediation phù hợp nhất là gì?

Kết thúc bài

Checklist trước khi sang Ngày 2