Nền tảng Resource Hierarchy: Kiến trúc phân cấp GCP

Tại sao điều này quan trọng trong production

GCP resource hierarchy không phải là tính năng optional—nó là nền tảng của tất cả security, billing, networking, và compliance decisions trên Google Cloud. Mỗi quyết định kiến trúc hệ thống phụ thuộc vào việc bạn hiểu rõ phân cấp này.

Các hậu quả của thiết kế sai:

Blast radius không kiểm soát: Nếu IAM policy được đặt ở mức organization thay vì folder, một lỗi có thể ảnh hưởng đến toàn bộ công ty
Cost allocation failures: Không thể theo dõi chi phí chính xác khi resource hierarchy không đúng
Network policy misconfiguration: Shared VPC design phụ thuộc hoàn toàn vào cấu trúc hierarchy
Compliance breaches: Sai hierarchy = không thể enforce organization policies hiệu quả
Operational burden: Phải maintain multiple overlapping policies nếu hierarchy bị phá hủy

Ở quy mô enterprise (1000+ projects), sai design của hierarchy có thể dẫn đến downtime toàn công ty, data breaches, hoặc violations regulatory compliance.

Kiến trúc phân cấp: The Four Tiers

GCP resource hierarchy là một rooted tree structure với chính xác 4 tầng:

Organization (root)
    ├── Folder (optional)
    │   ├── Folder (nested)
    │   │   └── Project
    │   └── Project
    └── Project

Tier 1: Organization Resource

Organization resource là root node của toàn bộ GCP hierarchy—tương đương khái niệm "tập đoàn" hoặc "công ty" trong GCP.

Điều kiện tiên quyết:

Phải có Google Workspace hoặc Cloud Identity account
Mỗi domain chỉ có thể associate với duy nhất một organization
Khi bất kỳ user nào trong domain tạo GCP project lần đầu, organization resource được tự động provisioned

Key characteristics của Organization:

Lifecycle binding: Tất cả projects và folders thuộc organization này—nếu một employee rời công ty, projects vẫn tồn tại và được bảo vệ
Centralized governance: Organization admins có quyền view/manage tất cả resources trong toàn công ty
Identity binding: Organization liên kết với Google Workspace customer ID (từ Directory API)
Policy inheritance point: Mọi IAM allow/deny policies, organization policies, audit logs đều bắt đầu từ organization

Một điểm quan trọng: Organization resource không được tạo bằng gcloud commands—nó tự động provisioned. Bạn chỉ có thể set IAM policies và organization policies trên nó sau khi được provisioned.

Production implications:

Nếu bạn không có organization, bạn không thể sử dụng folders—bị hạn chế governance
Nếu bạn cần multi-organization setup (rare case), phải xử lý bằng các workarounds (không supported chính thức)

Tier 2: Folder Resources

Folders là optional grouping mechanism giữa organization và projects. Tương tự như organizational units trong Active Directory.

Tại sao folders quan trọng:

Imagine công ty cơ cấu như sau:

Công ty (Organization)
├── Engineering (Folder)
│   ├── Backend team (Folder)
│   │   └── backend-prod, backend-staging projects
│   └── Frontend team (Folder)
│       └── frontend-prod, frontend-staging projects
├── Data (Folder)
│   ├── Data Engineering (Folder)
│   └── Analytics (Folder)
└── Finance (Folder)
    ├── Billing team
    └── FP&A team

Mỗi folder level là một policy attachment point. Bạn có thể:

Grant Editor role tới một team lead ở folder level → họ quản lý tất cả projects trong folder
Enforce organization policies (ví dụ: disable external IP) ở folder level → tự động apply tới tất cả child resources
Separate billing streams per department

Folder structure best practices cho production:

Mirror organizational structure, nhưng không quá sâu
- Recommendation: Tối đa 2-3 levels folder nesting
- Quá sâu = phức tạp policy inheritance, khó troubleshoot
- Mà "quá nông" = không đủ granularity cho governance
Folder vs Project cho isolation
- Folders = team/department boundary
- Projects = workload/environment boundary
- Không nên đặt tất cả prod resources vào cùng một folder rồi dùng labels để phân chia—dùng project separation
Budget allocation: Mỗi folder nên correspond với một cost center
- Tránh mix costs giữa các team vào cùng folder

Folder limitations:

Một project chỉ có thể có duy nhất một parent folder hoặc organization
Folders không thể renamed ở resource ID level (chỉ display name)
Moving projects between folders có implications lớn với VPC peering (xem chi tiết ở phần 09.shared-vpc-model.md)

Tier 3: Project Resource

Project là fundamental operating unit và trust boundary của GCP.

Các định danh của project:

json

{
  "projectId": "my-webapp-prod",          // 6-30 chars, globally unique, immutable
  "name": "My Web App - Production",      // display name, mutable, not unique
  "projectNumber": "123456789012",        // auto-assigned, immutable, unique
  "lifecycleState": "ACTIVE",             // ACTIVE, DELETE_IN_PROGRESS, DELETE_REQUESTED
  "parent": {
    "type": "folder",
    "id": "folders/987654321"
  }
}

Project ID vs Project Number vs Project Name:

Project ID: Unique identifier được dùng trong API calls, resource names, billing reports. Không thể thay đổi sau khi tạo.
Project Number: Automatically assigned, dùng ở internal Google systems. Ít khi cần nhưng important cho service account naming: PROJECT_NUMBER@cloudservices.gserviceaccount.com
Project Name: Display name, human-readable, không dùng trong APIs. Có thể thay đổi bất cứ lúc nào.

Common mistake: Developers thường nhầm lẫn project ID với project number khi làm automation. Ví dụ:

bash

# ❌ WRONG
gcloud config set project 123456789012  # project number

# ✅ CORRECT
gcloud config set project my-webapp-prod  # project ID

Lần đầu tiên project được set, nó báo lỗi nhầm lẫn—nhưng trong CI/CD scripts, điều này có thể gây silent failures.

Naming convention recommendations:

Sử dụng kebab-case (lowercase + hyphens): team-service-environment
Ví dụ: backend-api-prod, data-pipeline-staging, ml-training-dev
Không nên bao gồm sensitive info (customer IDs, API keys)—project ID xuất hiện ở logs, billing reports, URLs

Project as a trust boundary:

Trong GCP, resources trong cùng project mặc định có mức độ tin cậy cao hơn so với resources cross-project. Ví dụ:

Service accounts trong project A có thể access resources trong project A mà không cần additional IAM policy nếu quyền được granted ở project level
Service accounts trong project A phải có explicit cross-project IAM binding để access resources trong project B

Production pattern:

Environment per project: team-service-prod, team-service-staging, team-service-dev
Cách này cho phép: different quotas per environment, separate billing tracking, clear blast radius

Tier 4: Service Resources

Service resources (Compute Engine instances, Cloud Storage buckets, Cloud SQL databases, v.v.) sống inside projects.

Từ GCP hierarchy perspective, service resources được coi là leaf nodes—chúng inheriting policies từ project, nhưng không có children của riêng chúng.

Điều quan trọng: Resource-level IAM policies (ví dụ: granting viewer role trên một cụ thể Compute Engine instance) có thể được đặt, nhưng phải là subset của project-level permissions. Bạn không thể grant quyền ở resource level nếu user không có basic access tới project.

Policy Inheritance Mechanics

Khi một IAM policy được đặt ở một level trong hierarchy, tất cả child resources inherit policy đó—nhưng effective policy = union của:

Policies đặt trực tiếp trên resource
Policies inherited từ parents (organization → folder → project → resource)

Inheritance Model Chi Tiết

Organization (IAM policy: Organization Admin → admins@company.com)
    ↓ inherit
    Folder/Engineering (IAM policy: Folder Admin → eng-leads@company.com)
        ↓ inherit
        Project/backend-prod (IAM policy: Editor → backend-team@company.com)
            ↓ inherit
            Compute Engine instance (no explicit IAM)

Effective policy trên Compute Engine instance:
- Organization Admin (inherited)
- Folder Admin (inherited)
- Editor (inherited)

Cảnh báo: Role concentric hierarchy

Các basic roles (Owner, Editor, Viewer) có tính chất:

Owner ⊃ Editor ⊃ Viewer (subset relationships)

Nếu user đã có Editor role từ project level inheritance, granting Viewer role trên resource level không có effect—nó redundant.

bash

# Scenario: User có Editor role trên project, Viewer role được grant trên bucket
# Result: User vẫn có Editor permissions trên bucket (từ project inheritance)
# Viewer role từ bucket là redundant

Override Inheritance?

IAM không hỗ trợ "override" policies—chỉ có allow policies (union) hoặc deny policies (explicit deny).

Nếu bạn muốn prevent access, phải dùng:

Deny policies (newer, recommended)—explicit deny takes precedence
Remove user từ group (nếu policy dùng group)
Move resource tới folder với stricter policy

Production implication: Hãy design hierarchy sao cho default inheritance là safe. Ví dụ:

Không grant broad "Editor" role ở organization level—chỉ grant specific roles
Sử dụng groups và manage group membership

Resource Manager API: Programmatic View

Khi bạn query resource hierarchy qua API, Google Resource Manager API cho phép:

bash

# List all projects trong organization
gcloud projects list --filter="parent.id:ORGANIZATION_ID"

# Get folder details
gcloud resource-manager folders describe folders/FOLDER_ID

# Search resources (requires Cloud Asset Inventory)
gcloud asset search-all-resources \
  --scope=organizations/ORGANIZATION_ID \
  --asset-types=compute.googleapis.com/Instance

API inconsistency caveat: Resource Manager API có eventual consistency model. Khi bạn tạo project:

Project được created
IAM policies được applied
Billing account association diễn ra
Propagation delay: 5-30 seconds trước khi tất cả GCP services thấy project mới

Trong production automation, phải add retry logic khi tạo project:

python

# ❌ Risky
project = create_project(project_id)
set_iam_policy(project_id, policies)  # May fail if propagation not complete

# ✅ Safer
project = create_project(project_id)
time.sleep(10)  # or exponential backoff with retries
set_iam_policy(project_id, policies)

Caching Behavior & Eventual Consistency

GCP Resource Manager caches policy evaluations ở multiple levels:

Control plane: API server caches (few hundred ms)
Data plane: Service-specific caching (varies by service)
Local caching: Client libraries may cache (configurable)

Production scenario:

T=0: Admin thêm user vào group
T=5: IAM policy re-evaluated, user được add vào effective policy
T=10: GKE control plane thấy user có permission → pod được created
T=15: Kubelet thấy pod → container started

Nếu application expectations của "immediate policy enforcement", sẽ kecewa—phải account cho propagation delay.

Quota Hierarchy

Quotas ở GCP không inherit—chúng được independently managed ở mỗi level:

Organization-level quotas: Límite global (ví dụ: max projects = 10,000)
Folder-level quotas: Subset của organization quota
Project-level quotas: Individual project limits (tối phổ biến)

Production implication:

Organization quota = capacity planning tool
Project quota = blast radius control
Nếu project A hit quota, project B không bị impact

bash

# Request higher quota ở project level
gcloud compute quotas describe METRIC --project=PROJECT_ID

# Organization-level quota adjustment (limited support)
gcloud quotas info --project=ORGANIZATION_ID

Common Hierarchy Patterns

Pattern 1: Environment-per-Project (Recommended)

Organization
└── Folder/My-App
    ├── my-app-prod (project)
    ├── my-app-staging (project)
    └── my-app-dev (project)

Ưu điểm:

Clear blast radius isolation
Separate billing per environment
Different IAM policies per environment
Easy to restrict access (devs can't access prod)

Nhược điểm:

Nhiều project = nhiều thứ để manage
Cross-project resource sharing phức tạp

Pattern 2: Team-per-Folder (Recommended for large orgs)

Organization
├── Folder/Backend
│   ├── backend-prod
│   ├── backend-staging
│   └── backend-dev
├── Folder/Frontend
│   ├── frontend-prod
│   ├── frontend-staging
│   └── frontend-dev
└── Folder/Data
    ├── data-prod
    ├── data-staging
    └── data-dev

Ưu điểm:

Team-level governance
Centralized cost tracking per team
Folder-level permissions

Nhược điểm:

Phức tạp nếu services cross-team

Pattern 3: Hybrid (Shared Services + Team Projects)

Organization
├── Folder/Shared-Infrastructure
│   ├── networking (project)
│   ├── logging (project)
│   └── billing (project)
└── Folder/Teams
    ├── Folder/Backend-Team
    │   ├── backend-prod
    │   └── backend-dev
    └── Folder/Data-Team
        ├── data-prod
        └── data-dev

Ưu điểm:

Centralized networking (Shared VPC host)
Per-team environments
Billing aggregation possible

Testing Hierarchy Policies

Trước khi deploy production hierarchy changes, phải test:

bash

# Test if policy inheritance works
gcloud resource-manager org-policies list --folder=FOLDER_ID

# Dry-run org policy (preview feature)
gcloud resource-manager org-policies set-policy --dry-run FILE.yaml

# Check effective policy
gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --format="table(bindings.role)"

Best practice:

Test new hierarchy ở non-production folder trước
Validate IAM inheritance
Check quota compliance
Monitor audit logs 24-48h sebelum expanding ke production

Migration & Refactoring

Mengganti hierarchy ở production là operasi high-risk:

Moving project antara folders = potential service disruption (Shared VPC peering can break)
Changing organization policies = retroactive enforcement (existing resources might violate)
Adding folders retroactively = IAM inheritance side effects

Recommendation: Hierarchies should be designed correctly từ start. Nếu perlu change:

Plan migration carefully
Use dry-run policies
Test thoroughly ở staging
Execute outside business hours

Nền tảng Resource Hierarchy: Kiến trúc phân cấp GCP ​

Tại sao điều này quan trọng trong production ​

Kiến trúc phân cấp: The Four Tiers ​

Tier 1: Organization Resource ​

Tier 2: Folder Resources ​

Tier 3: Project Resource ​

Tier 4: Service Resources ​

Policy Inheritance Mechanics ​

Inheritance Model Chi Tiết ​

Override Inheritance? ​

Resource Manager API: Programmatic View ​

Caching Behavior & Eventual Consistency ​

Quota Hierarchy ​

Common Hierarchy Patterns ​

Pattern 1: Environment-per-Project (Recommended) ​

Pattern 2: Team-per-Folder (Recommended for large orgs) ​

Pattern 3: Hybrid (Shared Services + Team Projects) ​

Testing Hierarchy Policies ​

Migration & Refactoring ​

References ​

Nền tảng Resource Hierarchy: Kiến trúc phân cấp GCP

Tại sao điều này quan trọng trong production

Kiến trúc phân cấp: The Four Tiers

Tier 1: Organization Resource

Tier 2: Folder Resources

Tier 3: Project Resource

Tier 4: Service Resources

Policy Inheritance Mechanics

Inheritance Model Chi Tiết

Override Inheritance?

Resource Manager API: Programmatic View

Caching Behavior & Eventual Consistency

Quota Hierarchy

Common Hierarchy Patterns

Pattern 1: Environment-per-Project (Recommended)

Pattern 2: Team-per-Folder (Recommended for large orgs)

Pattern 3: Hybrid (Shared Services + Team Projects)

Testing Hierarchy Policies

Migration & Refactoring

References