Organization Policies — Constraints, Inheritance và Phân Biệt với IAM

IAM vs Organization Policy: Who vs What

Đây là sự phân biệt quan trọng nhất trong chapter này, và cần hiểu rõ trước khi đi vào chi tiết:

IAM kiểm soát WHO có thể thực hiện actions — identity-based, "alice có thể tạo VM không?"

Organization Policy kiểm soát WHAT configurations resource được phép có — resource-based, "VM trong org này có được phép có external IP không?"

Theo GCP documentation:

"Identity and Access Management focuses on who, and lets the administrator authorize who can take action on specific resources based on permissions. Organization Policy focuses on what, and lets the administrator set restrictions on specific resources to determine how they can be configured."

Hệ quả: Organization Policy có thể block một action kể cả khi user có đủ IAM permissions. Một user với roles/compute.instanceAdmin có quyền IAM để tạo VM với external IP, nhưng nếu Organization Policy restrict external IPs, API call sẽ bị reject trước khi IAM được evaluate.

---

Enforcement layer: Org Policy enforce ở đâu

Organization Policies enforce ở GCP API resource layer — nghĩa là tại thời điểm một GCP API call được thực hiện để thay đổi configuration của resource. Cụ thể hơn, enforcement xảy ra trong Resource Manager và các GCP services tích hợp Org Policy.

User/Workload calls API
    │
    ▼
┌─────────────────────────────────────────┐
│ GCP API Server                          │
│                                         │
│ 1. Organization Policy check (đầu tiên) │ ← Enforce ở đây
│    → Constraint violation? → 403 POLICY │
│                                         │
│ 2. IAM check (sau Org Policy)           │
│    → PAB → Deny → Allow                 │
│                                         │
│ 3. Resource operation                   │
└─────────────────────────────────────────┘

Khi Org Policy violation, error response có format:

{
  "error": {
    "code": 403,
    "message": "Constraint 'constraints/compute.vmExternalIpAddresses' violated",
    "status": "PERMISSION_DENIED"
  }
}

Và một Policy Denied Audit Log được tạo ra (loại log này luôn on, miễn phí).

---

Constraint types: Bốn loại chính

1. Managed Constraints (Modern, Google-defined)

Đây là hướng hiện đại của GCP Org Policies. Managed constraints được Google define và maintain, hỗ trợ parameterization linh hoạt hơn legacy constraints.

Ví dụ: constraints/iam.allowedPolicyMemberDomains — chỉ cho phép members từ những domains cụ thể trong IAM policies.

# Liệt kê managed constraints available
gcloud org-policies list-managed-constraints \
  --organization=ORG_ID

2. Legacy List Constraints

Constraints cũ hơn, sử dụng model "allow list" hoặc "deny list" với các values.

Deny list (restrictive): Tất cả values được phép trừ những values trong list

name: organizations/ORG_ID/policies/constraints/compute.vmExternalIpAddresses
spec:
  rules:
  - values:
      deniedValues:
      - projects/my-project/regions/us-central1/addresses/*
  inheritFromParent: false

Allow list (permissive): Chỉ những values trong list được phép

name: organizations/ORG_ID/policies/constraints/gcp.resourceLocations
spec:
  rules:
  - values:
      allowedValues:
      - in:us-locations
      - in:asia-southeast1-locations
  inheritFromParent: true

Phủ nhận toàn bộ với deny: all: Block tất cả values

spec:
  rules:
  - denyAll: "TRUE"

3. Legacy Boolean Constraints

Đơn giản nhất — một constraint có thể được "enforced" hoặc "not enforced":

# Disable default SA Editor role grant
name: organizations/ORG_ID/policies/constraints/iam.automaticIamGrantsForDefaultServiceAccounts
spec:
  rules:
  - enforce: true

Các boolean constraints thường được biểu thị theo convention: nếu enforced = "hành vi bị restrict". Ví dụ:

• compute.disableSerialPortAccess: enforced = serial port access bị disable
• iam.disableServiceAccountKeyCreation: enforced = không tạo được SA keys

4. Custom Constraints

Custom constraints cho phép tổ chức tự define constraints dựa trên CEL expressions evaluate trên resource attributes. Đây là cơ chế mạnh nhất và cũng phức tạp nhất.

Custom constraints chỉ hỗ trợ Create và Update operations (không hỗ trợ Delete).

# Custom constraint: VM phải có label "cost-center"
name: organizations/ORG_ID/customConstraints/custom.requireCostCenterLabel
resourceTypes:
- compute.googleapis.com/Instance
methodTypes:
- CREATE
- UPDATE
condition: "resource.labels.exists(label, label == 'cost-center')"
actionType: ALLOW
displayName: "Require cost-center label on VMs"
description: "VM phải có label cost-center để track billing attribution"

Trong CEL expression của custom constraint:

• resource: Object đại diện cho resource đang được tạo/updated
• Có thể access mọi field của resource (phụ thuộc vào resource type)

Sau khi tạo custom constraint, phải create policy để enforce nó:

name: organizations/ORG_ID/policies/custom.requireCostCenterLabel
spec:
  rules:
  - enforce: true

---

Inheritance model: Trickle down với merge rules

Org Policies kế thừa từ Organizations → Folders → Projects theo chiều từ trên xuống. Nhưng ngữ nghĩa kế thừa phức tạp hơn IAM:

Legacy constraints: Inheritance với merge

Với legacy constraints (list và boolean), khi inheritFromParent: true:

• Parent policy và child policy được merged (không phải override)
• Merge semantics tùy thuộc vào loại constraint

Với allow list: Child chỉ có thể restrict (thu hẹp) danh sách từ parent, không thể expand. Nếu parent allow us-locations, child không thể thêm europe-locations.

Với deny list: Child có thể thêm values vào deny list (tức là restrict thêm).

Với boolean: Nếu parent enforce, child không thể unenforce.

Managed constraints: Không merge — override

Managed constraints không merge với parent — child policy override parent hoàn toàn. Điều này cho phép child có policy khác với parent (không chỉ restrict hơn).

Reset về ancestor policy

spec:
  reset: true  # Reset về policy của ancestor (inherited default)

Dùng reset để xóa custom policy tại một node và fall back về ancestor's policy.

---

Commonly used constraints trong production

IAM-related constraints

Constraint	Mục đích
iam.allowedPolicyMemberDomains	Chỉ cho phép identities từ specific domains trong IAM policies — ngăn external users được grant access
iam.disableServiceAccountKeyCreation	Ngăn tạo SA keys — force dùng Workload Identity
iam.disableServiceAccountKeyUpload	Ngăn upload user-managed keys cho SA
iam.automaticIamGrantsForDefaultServiceAccounts	Ngăn auto-grant Editor role cho default SAs
iam.restrictCrossProjectServiceAccountLimpersonation	Restrict SA impersonation xuyên project

Resource configuration constraints

Constraint	Mục đích
compute.vmExternalIpAddresses	Restrict/deny VM external IPs
compute.requireOsLogin	Bắt buộc OS Login cho SSH access
compute.disableSerialPortAccess	Disable serial port (thường dùng cho debugging, có thể bị exploit)
gcp.resourceLocations	Restrict resources vào specific regions (data residency)
compute.restrictCloudSQLInstances	Restrict Cloud SQL instance types/configs
storage.uniformBucketLevelAccess	Bắt buộc uniform bucket-level access (disable per-object ACLs)
storage.publicAccessPrevention	Ngăn GCS buckets được public (allUsers)
run.allowedIngress	Restrict ingress cho Cloud Run services

---

Org Policy inheritance và IAM: Tương tác quan trọng

Org Policy không check IAM

Quan trọng: Org Policy không check IAM permissions khi enforce. Ngay cả user với roles/orgpolicy.policyAdmin (quyền manage org policies) cũng bị block bởi org policy nếu họ cố tạo resource vi phạm policy — không phải họ được bypass vì có admin role.

Điều này là intentional: Org Policy là safeguard ở organization level, không phải ở individual user level.

Org Policy admin có thể modify policy chính sách

roles/orgpolicy.policyAdmin cho phép create, update, delete org policies. Nếu user có role này, họ có thể modify policy để allow resource type mà họ muốn tạo, rồi create resource, rồi revert policy — một privilege escalation pattern cần kiểm soát.

Trong security-critical organizations: roles/orgpolicy.policyAdmin nên được restrict chặt, và mọi Org Policy changes phải được log và alert.

---

Policy Intelligence: Dry-run và Simulation

Trước khi apply Org Policy vào production, dùng dry-run để test:

# Simulate effect của một org policy
gcloud org-policies simulate-policy \
  --organization=ORG_ID \
  --policy=policy.yaml

# Kết quả cho biết resources nào sẽ bị affect nếu apply policy

Hoặc dùng Policy Simulator trong Cloud Console để visualize impact.

---

Custom Constraints: Power và Responsibility

Custom constraints với CEL cho phép enforce business rules rất specific. Nhưng cần cẩn thận:

Chỉ evaluate khi create/update: Custom constraints không retroactively affect existing resources. Nếu tạo constraint "VM phải có label X", các VM hiện tại không có label X vẫn tồn tại và hoạt động bình thường — chỉ create/update mới bị block.

Phải test kỹ CEL expression: Một CEL expression sai trong custom constraint có thể block mọi VM creation trong org. Luôn test với dry-run trước.

Performance: Complex CEL expressions có thể thêm latency vào API calls. Giữ expressions đơn giản.

---

References

• Organization Policy overview
• Understanding Organization Policies
• Custom constraints
• IAM-related organization policy constraints
• Organization policy constraint reference