🔐 IAM Model

Level: Foundation Solves: Thiết kế và quản lý identity & access management theo chuẩn enterprise security trên GCP

🎯 Mục tiêu (Outcomes)

Sau khi áp dụng kiến thức trong trang này, bạn sẽ có khả năng:

Thiết kế IAM Strategy với predefined và custom roles
Triển khai Workload Identity cho GKE workloads
Cấu hình Service Account Impersonation thay cho SA keys
Áp dụng IAM Conditions cho fine-grained access control
Implement Least Privilege với IAM Recommender
So sánh với AWS IAM model

✅ Khi nào dùng

Pattern	Use Case	Lý do
Workload Identity	GKE pods access GCP	No keys, automatic rotation
SA Impersonation	Cross-project access	Audit trail, short-lived
Predefined Roles	Standard use cases	Well-scoped, maintained
Custom Roles	Specific requirements	Exact permissions needed
IAM Conditions	Time-based, resource-based	Fine-grained control

❌ Khi nào KHÔNG dùng

Pattern	Vấn đề	Thay thế
Basic roles (Editor/Owner)	Quá broad	Predefined roles
Service Account keys	Key leak risk	Workload Identity
Default SAs	Editor role by default	User-managed SAs
Individual user bindings	Hard to manage	Google Groups
allUsers/allAuthenticatedUsers	Public access	Specific principals

⚠️ Cảnh báo từ Raizo

"Một SA key commit vào GitHub. 30 phút sau, crypto miners đã deploy 50 n8-highmem-96 VMs. $15,000 bill trong 1 ngày. Organization Policy 'Disable SA key creation' là cần thiết."

Core Concepts

GCP IAM Components

┌─────────────────────────────────────────────────────────────────┐
│                    GCP IAM MODEL                                │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  WHO (Principal)          WHAT (Role)         WHERE (Resource)  │
│  ──────────────           ──────────          ────────────────  │
│                                                                 │
│  ┌─────────────┐         ┌─────────────┐     ┌─────────────┐   │
│  │ Google Acct │         │   Viewer    │     │Organization │   │
│  │ Service Acct│   +     │   Editor    │  →  │   Folder    │   │
│  │   Group     │         │   Owner     │     │   Project   │   │
│  │  allUsers   │         │Custom Roles │     │  Resource   │   │
│  └─────────────┘         └─────────────┘     └─────────────┘   │
│                                                                 │
│  IAM Policy = Collection of bindings:                           │
│  { principal + role + resource + (optional) condition }         │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Principal Types

Principal Type	Format	Use Case
Google Account	`user:email@example.com`	Human users
Service Account	`serviceAccount:sa@project.iam.gserviceaccount.com`	Applications
Google Group	`group:team@example.com`	Team access
Cloud Identity Domain	`domain:example.com`	All domain users
allUsers	`allUsers`	Public access (dangerous!)
allAuthenticatedUsers	`allAuthenticatedUsers`	Any Google account

Role Types

Role Hierarchy

┌─────────────────────────────────────────────────────────────────┐
│                    GCP ROLE TYPES                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  BASIC ROLES (Legacy - Avoid in Enterprise)                     │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ • roles/viewer    - Read-only access                    │    │
│  │ • roles/editor    - Read + Write (NO IAM, NO Billing)   │    │
│  │ • roles/owner     - Full control including IAM          │    │
│  │                                                         │    │
│  │ ⚠️ TOO BROAD - Use predefined or custom roles instead   │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                 │
│  PREDEFINED ROLES (Recommended)                                 │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ • roles/compute.instanceAdmin.v1                        │    │
│  │ • roles/storage.objectViewer                            │    │
│  │ • roles/bigquery.dataEditor                             │    │
│  │ • roles/cloudsql.client                                 │    │
│  │                                                         │    │
│  │ ✅ Scoped to specific services and actions              │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                 │
│  CUSTOM ROLES (When predefined don't fit)                       │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ • Define exact permissions needed                       │    │
│  │ • Can be org-level or project-level                     │    │
│  │ • Requires maintenance as APIs evolve                   │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Custom Role Example

yaml

title: "Application Deployer"
description: "Deploy applications to Cloud Run"
stage: GA
includedPermissions:
  - run.services.get
  - run.services.list
  - run.services.create
  - run.services.update
  - run.revisions.get
  - run.revisions.list
  - artifactregistry.repositories.downloadArtifacts

⚠️ Custom Role Maintenance

Custom roles require ongoing maintenance. When GCP adds new permissions to services, custom roles don't automatically include them. Review quarterly.

Service Accounts

Service Account Types

┌─────────────────────────────────────────────────────────────────┐
│                SERVICE ACCOUNT TYPES                            │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  DEFAULT SERVICE ACCOUNTS (Avoid)                               │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ • Compute Engine default SA                             │    │
│  │   {project-number}-compute@developer.gserviceaccount.com│    │
│  │ • App Engine default SA                                 │    │
│  │   {project-id}@appspot.gserviceaccount.com              │    │
│  │                                                         │    │
│  │ ⚠️ Has Editor role by default - TOO PERMISSIVE          │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                 │
│  USER-MANAGED SERVICE ACCOUNTS (Recommended)                    │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ • Create dedicated SA per application/workload          │    │
│  │ • Grant minimum required permissions                    │    │
│  │ • Use meaningful names: {app}-{env}@{project}.iam...    │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                 │
│  GOOGLE-MANAGED SERVICE ACCOUNTS                                │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ • Created by GCP services automatically                 │    │
│  │ • Example: Cloud Build, Dataflow service agents         │    │
│  │ • Don't modify unless necessary                         │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Service Account Best Practices

Workload Identity

GKE Workload Identity

┌─────────────────────────────────────────────────────────────────┐
│                 WORKLOAD IDENTITY                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │                    GKE Cluster                          │    │
│  │  ┌─────────────────────────────────────────────────┐    │    │
│  │  │              Kubernetes Namespace               │    │    │
│  │  │  ┌─────────────────────────────────────────┐    │    │    │
│  │  │  │           Pod                           │    │    │    │
│  │  │  │  ┌─────────────────────────────────┐    │    │    │    │
│  │  │  │  │  K8s Service Account            │    │    │    │    │
│  │  │  │  │  (my-app-ksa)                   │    │    │    │    │
│  │  │  │  └──────────────┬──────────────────┘    │    │    │    │
│  │  │  └─────────────────┼───────────────────────┘    │    │    │
│  │  └────────────────────┼────────────────────────────┘    │    │
│  └───────────────────────┼─────────────────────────────────┘    │
│                          │                                      │
│                          │ Workload Identity binding             │
│                          ▼                                      │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │              GCP Service Account                        │    │
│  │              (my-app-gsa@project.iam...)                │    │
│  │                         │                               │    │
│  │                         ▼                               │    │
│  │              ┌─────────────────────┐                    │    │
│  │              │   GCP Resources     │                    │    │
│  │              │   (BigQuery, GCS)   │                    │    │
│  │              └─────────────────────┘                    │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                 │
│  NO SERVICE ACCOUNT KEYS NEEDED!                                │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Workload Identity Setup

bash

# 1. Enable Workload Identity on cluster
gcloud container clusters update CLUSTER_NAME \
  --workload-pool=PROJECT_ID.svc.id.goog

# 2. Create GCP Service Account
gcloud iam service-accounts create my-app-gsa \
  --display-name="My App Service Account"

# 3. Grant permissions to GCP SA
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:my-app-gsa@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/bigquery.dataViewer"

# 4. Allow K8s SA to impersonate GCP SA
gcloud iam service-accounts add-iam-policy-binding \
  my-app-gsa@PROJECT_ID.iam.gserviceaccount.com \
  --role="roles/iam.workloadIdentityUser" \
  --member="serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"

# 5. Annotate K8s Service Account
kubectl annotate serviceaccount KSA_NAME \
  --namespace NAMESPACE \
  iam.gke.io/gcp-service-account=my-app-gsa@PROJECT_ID.iam.gserviceaccount.com

IAM Conditions

Conditional Access

json

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": ["user:developer@example.com"],
      "condition": {
        "title": "Business hours only",
        "description": "Access only during business hours",
        "expression": "request.time.getHours('Asia/Ho_Chi_Minh') >= 9 && request.time.getHours('Asia/Ho_Chi_Minh') <= 18"
      }
    }
  ]
}

Common Condition Patterns

yaml

# Time-based access
expression: |
  request.time.getHours("Asia/Ho_Chi_Minh") >= 9 &&
  request.time.getHours("Asia/Ho_Chi_Minh") <= 18 &&
  request.time.getDayOfWeek("Asia/Ho_Chi_Minh") >= 1 &&
  request.time.getDayOfWeek("Asia/Ho_Chi_Minh") <= 5

# Resource name prefix
expression: |
  resource.name.startsWith("projects/_/buckets/prod-")

# Tag-based access
expression: |
  resource.matchTag("env", "production")

# Temporary access (expires)
expression: |
  request.time < timestamp("2024-12-31T23:59:59Z")

Service Account Impersonation

Impersonation Chain

┌─────────────────────────────────────────────────────────────────┐
│            SERVICE ACCOUNT IMPERSONATION                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  User/SA A                                                      │
│      │                                                          │
│      │ Has: roles/iam.serviceAccountTokenCreator                │
│      │ On: SA B                                                 │
│      ▼                                                          │
│  Service Account B                                              │
│      │                                                          │
│      │ Has: roles/storage.admin                                 │
│      │ On: GCS Bucket                                           │
│      ▼                                                          │
│  GCS Bucket                                                     │
│                                                                 │
│  Command:                                                       │
│  gcloud storage ls gs://bucket \                                │
│    --impersonate-service-account=sa-b@project.iam...            │
│                                                                 │
│  ✅ No SA keys needed                                           │
│  ✅ Audit trail shows impersonation                             │
│  ✅ Short-lived credentials                                     │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

GCP vs AWS IAM Comparison

Concept	GCP	AWS
Identity	Google Account, Service Account	IAM User, IAM Role
Groups	Google Groups (external)	IAM Groups (internal)
Roles	Predefined + Custom	Managed + Customer
Policy Attachment	Binding at resource level	Attach to identity
Temporary Credentials	Impersonation, Workload Identity	AssumeRole, STS
Cross-Account	Cross-project IAM	Cross-account roles
Conditions	CEL expressions	IAM Conditions

Best Practices Checklist

[ ] No basic roles (viewer/editor/owner) in production
[ ] Service accounts per workload, not shared
[ ] Workload Identity for GKE workloads
[ ] No service account keys (use impersonation)
[ ] Groups for human access, not individual bindings
[ ] IAM conditions for sensitive resources
[ ] Regular access reviews with IAM Recommender
[ ] Audit logs enabled for IAM changes

⚖️ Trade-offs

Trade-off 1: Predefined vs Custom Roles

Khía cạnh	Predefined Roles	Custom Roles
Maintenance	Google maintains	You maintain
Granularity	Fixed	Exact permissions
Updates	Automatic	Manual review
Audit	Standard	Custom audit

Khuyến nghị: Predefined là default. Custom chỉ khi predefined quá broad hoặc too restrictive.

Trade-off 2: SA Keys vs Workload Identity

Khía cạnh	SA Keys	Workload Identity
Setup	Simple	Complex
Security	Key leak risk	No keys
Rotation	Manual	Automatic
Portability	Any environment	GCP only

Trade-off 3: Granular vs Simple IAM

Approach	Granularity	Manageability
Role per resource	Very fine	Complex
Role per project	Medium	Balanced
Role per folder	Coarse	Simple

🚨 Failure Modes

Failure Mode 1: Service Account Key Leak

🔥 Incident thực tế

Developer commit SA key vào public repo. Bot detect trong 10 phút. Attackers spin up GPU VMs cho crypto mining. $50K bill before detection.

Cách phát hiện	Cách phòng tránh
Unusual API activity	Disable SA key creation (org policy)
Cost spike	Use Workload Identity
GitHub secret scanning	Pre-commit hooks
Security Command Center	Short-lived tokens only

Failure Mode 2: Over-Privileged Service Account

Cách phát hiện	Cách phòng tránh
IAM Recommender alerts	Start with minimal permissions
Unused permissions	Regular access reviews
Editor role on default SA	Remove Editor from default SAs

Failure Mode 3: IAM Policy Conflicts

Cách phát hiỆn	Cách phòng tránh
Access denied unexpectedly	Test in sandbox
Policy troubleshooter errors	Document inheritance
Conflicting conditions	Use policy analyzer

🔐 Security Baseline

IAM Security Requirements

Requirement	Implementation	Verification
No SA keys	Org policy enforced	Security Command Center
No basic roles	Policy analyzer	IAM Recommender
Workload Identity	GKE configuration	Cluster audit
IAM audit logs	Cloud Logging	Log sink verified
Groups for humans	Google Groups	User binding audit

Service Account Security

yaml

# Minimum SA permissions pattern
resources:
  - type: "iam.googleapis.com/ServiceAccount"
    properties:
      name: "my-app-sa"
    bindings:
      - role: "roles/iam.serviceAccountUser"
        members:
          - "serviceAccount:deployer@project.iam.gserviceaccount.com"
      - role: "roles/iam.workloadIdentityUser"
        members:
          - "serviceAccount:project.svc.id.goog[namespace/ksa]"

📊 Ops Readiness

Metrics cần Monitoring

Metric	Source	Alert Threshold
SA key creation	Audit Logs	Any
Unused permissions	IAM Recommender	> 10% unused
Basic role usage	Policy Analyzer	Any in prod
allUsers bindings	Security Command Center	Any
Failed auth attempts	Audit Logs	Spike

Runbook Entry Points

Tình huống	Runbook
SA key leak	`runbook/sa-key-rotation.md`
Over-privileged SA detected	`runbook/iam-remediation.md`
Access denied investigation	`runbook/iam-troubleshooting.md`
IPolicyCrossover violation	`runbook/iam-recommender-review.md`
Workload Identity setup	`runbook/workload-identity-setup.md`

✅ Design Review Checklist

Identity

[ ] No SA keys in use
[ ] Workload Identity for GKE
[ ] SA impersonation configured
[ ] Groups cho human access

Authorization

[ ] No basic roles
[ ] Predefined roles preferred
[ ] Custom roles documented
[ ] IAM conditions where needed

Audit

[ ] IAM audit logs enabled
[ ] Regular recommender review
[ ] Access reviews scheduled
[ ] Policy analyzer runs

Operations

[ ] SA inventory maintained
[ ] Permission documentation
[ ] Runbooks available
[ ] Training completed

📎 Liên kết

📎 AWS IAM Fundamentals - So sánh với AWS IAM model
📎 Resource Hierarchy - IAM inheritance trong hierarchy
📎 Security & Data Perimeter - IAM trong VPC Service Controls
📎 Terraform Security - Quản lý IAM qua IaC
📎 GCP Compute - SA cho compute workloads

🔐 IAM Model ​

🎯 Mục tiêu (Outcomes) ​

✅ Khi nào dùng ​

❌ Khi nào KHÔNG dùng ​

Core Concepts ​

GCP IAM Components ​

Principal Types ​

Role Types ​

Role Hierarchy ​

Custom Role Example ​

Service Accounts ​

Service Account Types ​

Service Account Best Practices ​

Workload Identity ​

GKE Workload Identity ​

Workload Identity Setup ​

IAM Conditions ​

Conditional Access ​

Common Condition Patterns ​

Service Account Impersonation ​

Impersonation Chain ​

GCP vs AWS IAM Comparison ​

Best Practices Checklist ​

⚖️ Trade-offs ​

Trade-off 1: Predefined vs Custom Roles ​

Trade-off 2: SA Keys vs Workload Identity ​

Trade-off 3: Granular vs Simple IAM ​

🚨 Failure Modes ​

Failure Mode 1: Service Account Key Leak ​

Failure Mode 2: Over-Privileged Service Account ​

Failure Mode 3: IAM Policy Conflicts ​

🔐 Security Baseline ​

IAM Security Requirements ​

Service Account Security ​

📊 Ops Readiness ​

Metrics cần Monitoring ​

Runbook Entry Points ​

✅ Design Review Checklist ​

Identity ​

Authorization ​

Audit ​

Operations ​

📎 Liên kết ​

🔐 IAM Model

🎯 Mục tiêu (Outcomes)

✅ Khi nào dùng

❌ Khi nào KHÔNG dùng

Core Concepts

GCP IAM Components

Principal Types

Role Types

Role Hierarchy

Custom Role Example

Service Accounts

Service Account Types

Service Account Best Practices

Workload Identity

GKE Workload Identity

Workload Identity Setup

IAM Conditions

Conditional Access

Common Condition Patterns

Service Account Impersonation

Impersonation Chain

GCP vs AWS IAM Comparison

Best Practices Checklist

⚖️ Trade-offs

Trade-off 1: Predefined vs Custom Roles

Trade-off 2: SA Keys vs Workload Identity

Trade-off 3: Granular vs Simple IAM

🚨 Failure Modes

Failure Mode 1: Service Account Key Leak

Failure Mode 2: Over-Privileged Service Account

Failure Mode 3: IAM Policy Conflicts

🔐 Security Baseline

IAM Security Requirements

Service Account Security

📊 Ops Readiness

Metrics cần Monitoring

Runbook Entry Points

✅ Design Review Checklist

Identity

Authorization

Audit

Operations

📎 Liên kết