Chapter 31: IAM Deep Dive — Model, Propagation, Conditions
Tại sao chương này critical
IAM (Identity and Access Management) là lớp access control duy nhất và phổ quát trong GCP. Mọi API call — từ một developer gcloud trên terminal đến một Pod trong GKE gọi Cloud Storage — đều phải đi qua IAM authorization engine. Không có bypass nào ngoài VPC Service Controls (vốn là một lớp bổ sung orthogonal với IAM).
Điều khiến IAM trong GCP phức tạp hơn nhiều so với AWS hay Azure là sự phân tầng chính sách: một request có thể bị kiểm soát đồng thời bởi Principal Access Boundary, Deny Policy, Allow Policy, IAM Conditions, Organization Policy và VPC Service Controls — mỗi lớp có ngữ nghĩa và thứ tự evaluation riêng. Hiểu sai bất kỳ lớp nào có thể dẫn đến privilege escalation hoặc bị từ chối access không mong muốn.
Chương này phân tích cơ chế bên trong của từng thành phần — không phải hướng dẫn cấu hình, mà là mental model chính xác để engineer có thể reason về hệ thống, debug access issues, và thiết kế least-privilege architecture đúng từ đầu.
Điều kiện tiên quyết
- Chapter 1: Resource Hierarchy — Organization, Folder, Project, Resource
- Kubernetes RBAC fundamentals (để so sánh mô hình)
- Hiểu cơ bản về OAuth 2.0 token và JWT
Nội dung chapter
1. IAM Policy Model — Allow Policy, Evaluation Order, PAB
Ba loại policy (Allow, Deny, PAB), cấu trúc allow policy (bindings), các loại principal, quá trình evaluation 3 pha (PAB → Deny → Allow), và cách effective policy được tổng hợp từ hierarchy.
2. Role Types — Basic, Predefined, Custom
Cấu trúc và giới hạn của basic roles (tại sao nguy hiểm trong production), predefined roles và cách Google quản lý chúng, thiết kế và giới hạn của custom roles, permission naming convention.
3. Policy Hierarchy & Propagation — Inheritance và Eventual Consistency
Cơ chế kế thừa policy theo resource hierarchy, cách IAM tổng hợp effective policy, eventual consistency model, caching behavior và propagation delay — những điều engineer cần biết khi debug access issues.
4. IAM Conditions & CEL Expressions
Common Expression Language trong IAM: time-based conditions, resource-based conditions, request-based conditions. Cơ chế evaluation, limitations quan trọng, và anti-patterns phổ biến.
5. IAM Deny Policies — Deny Before Allow
Cơ chế deny policy, thứ tự evaluation (deny-before-allow), cấu trúc deny rule, deniable permissions, exception mechanisms, và sự khác biệt quan trọng so với allow policies.
6. Service Accounts — Key Management, Impersonation, Default SA Dangers
Ba loại service account, rủi ro của SA keys, cơ chế impersonation và short-lived credentials, nguy hiểm của default service accounts và cách mitigate.
7. Audit Logging — Admin Activity, Data Access, Policy Denied
Bốn loại Cloud Audit Logs trong IAM context, log structure và metadata, cách enable Data Access logs, chi phí và chiến lược retention.
8. VPC Service Controls — Access Control Orthogonal với IAM
VPC-SC như lớp API-layer perimeter security trực giao với IAM, cơ chế enforcement, sự khác biệt quan trọng so với firewall và IAM, và vị trí của VPC-SC trong mô hình evaluation tổng thể.
9. Organization Policies — Constraints và Inheritance
Organization Policy Service: phân biệt với IAM (what vs who), các loại constraint (list, boolean, managed, custom), cơ chế inheritance, và cách org policies complement IAM trong defense-in-depth.
10. IAM Recommender — Least-Privilege Automation
Cơ chế nội tại của IAM Recommender: 90-day observation window, ML-based permission co-occurrence, các loại recommendation (remove/replace/replace-customizable), và giới hạn quan trọng cần biết trước khi tin vào recommendations.
Mental model tổng quan: IAM evaluation pipeline
Một IAM authorization check thực sự trải qua ba pha tuần tự (không phải một bước đơn giản):
Request đến API
│
▼
┌─────────────────────────────────────────────┐
│ Pha 1: PAB Check (Principal Access Boundary)│
│ → Principal có được phép truy cập resource │
│ này không? (resource eligibility) │
└─────────────────────────────────────────────┘
│ Pass
▼
┌─────────────────────────────────────────────┐
│ Pha 2: Deny Policy Check │
│ → Có deny rule nào áp dụng cho action này │
│ không? (deny-before-allow) │
└─────────────────────────────────────────────┘
│ No deny
▼
┌─────────────────────────────────────────────┐
│ Pha 3: Allow Policy Check │
│ → Có role binding nào grant permission này │
│ không? (effective policy từ hierarchy) │
└─────────────────────────────────────────────┘
│ Granted
▼
Access
GrantedOrganization Policy được evaluate ở một lớp riêng biệt — không phải trong IAM pipeline — mà ở tầng GCP API resource enforcement, trước khi IAM được gọi.
Tham khảo nhanh: Sự khác biệt giữa các lớp access control
| Lớp | Kiểm soát gì | Enforce ở đâu |
|---|---|---|
| Organization Policy | What — cấu hình resource | GCP API layer |
| PAB Policy | Where — resource eligibility | IAM (Pha 1) |
| Deny Policy | Prevent who — block permissions | IAM (Pha 2) |
| Allow Policy | Who can do what — grant permissions | IAM (Pha 3) |
| VPC Service Controls | Context-based perimeter — API access | API Gateway/GFE |