Hierarchical Firewall Policies — Thi Hành Ở Tầng Tổ Chức
Tại sao quan trọng trong production
VPC firewall rules là công cụ tốt cho một project, một team. Nhưng khi tổ chức có hàng chục project, hàng trăm VPC, và các team khác nhau, bạn gặp một vấn đề cơ bản: không có cơ chế nào đảm bảo một rule tồn tại trên tất cả các networks. Một team có thể vô tình xóa rule chặn SSH access từ internet. Một project mới được tạo và không có rule baseline nào.
Hierarchical Firewall Policies (HFP) giải quyết vấn đề này bằng cách đưa firewall enforcement lên tầng resource hierarchy — org và folder level — nơi individual teams không có quyền modify. Rules ở đây enforce từ trên xuống và không thể bị override bởi project-level configuration.
Hiểu HFP là bắt buộc cho platform engineers và security teams chịu trách nhiệm về compliance và baseline security posture của một GCP organization.
Internal Model — Cơ Chế Hoạt Động Bên Trong
HFP là resource trong resource hierarchy
Khác với VPC firewall rules (gắn với một VPC network cụ thể), một Hierarchical Firewall Policy là một GCP resource tồn tại ở cấp organization hoặc folder. Một policy có thể được associate (gắn kết) với nhiều folders hoặc organization.
Quan trọng: tạo policy chưa phải là enforce policy. Phải có bước association riêng biệt để policy bắt đầu có hiệu lực trên một folder/org.
Organization
├── HFP: "baseline-deny-ssh" [ASSOCIATED với Org]
├── Folder: "production"
│ ├── HFP: "prod-allow-monitoring" [ASSOCIATED với Folder "production"]
│ ├── Project A
│ │ ├── VPC Network "main"
│ │ │ └── VPC Firewall Rules (project-level)
│ │ └── Network Firewall Policy (project-level)
│ └── Project B
└── Folder: "development"
└── (không có HFP riêng → inherit từ Org)Evaluation order — Thứ tự thi hành nhiều tầng
Khi một packet đến một VM, firewall evaluation đi qua nhiều tầng theo thứ tự từ cao xuống thấp trong hierarchy:
1. Org-level HFP rules
2. Folder-level HFP rules (theo thứ tự từ folder gần nhất lên)
3. Global Network Firewall Policies
4. Regional Network Firewall Policies
5. VPC Firewall Rules (legacy)
6. Implied rules (deny-all ingress, allow-all egress)Mỗi rule trong mỗi tầng được evaluate theo priority (số nhỏ = ưu tiên cao). Khi một rule match và có action terminal (ALLOW hoặc DENY), evaluation dừng lại và action đó được thực thi. Khi action là goto_next, evaluation tiếp tục xuống tầng tiếp theo.
Nguyên tắc bất biến: "Lower-level rules cannot override a rule from a higher place in the resource hierarchy."
Nếu org-level policy có DENY rule cho SSH từ internet ở priority 100, không có bất kỳ project-level rule nào có thể override điều đó — dù project admin add ALLOW port 22 với priority 0.
goto_next — Cơ chế delegation
goto_next là action duy nhất trong HFP không có trong VPC firewall rules. Nó cho phép một rule "bỏ qua" việc đưa ra quyết định terminal và để tầng thấp hơn quyết định.
Mental model đúng cho goto_next:
ALLOW: "Tôi quyết định cho phép traffic này. Dừng evaluation."DENY: "Tôi quyết định chặn traffic này. Dừng evaluation."goto_next: "Rule này match, nhưng tôi không muốn quyết định ở tầng này. Tiếp tục xuống tầng dưới."
Use case quan trọng: Security team ở org level muốn đảm bảo SSH bị block từ internet ở tất cả production environments, nhưng muốn cho phép exception ở development folder. Cấu hình:
Org-level policy:
priority: 100, direction: INGRESS, source: 0.0.0.0/0, port: 22, action: DENYDevelopment folder-level policy:
priority: 50, direction: INGRESS, source: "dev-office-ip/32", port: 22, action: ALLOW
priority: 100, direction: INGRESS, source: 0.0.0.0/0, port: 22, action: goto_nextTrong trường hợp này:
- Traffic SSH từ office IP đến development: match folder rule priority 50 → ALLOW (terminal)
- Traffic SSH từ bất kỳ IP nào khác đến development: match folder rule priority 100 → goto_next → xuống tầng dưới... không match VPC rules → match org rule priority 100 → DENY
Khoan đã — vấn đề: org-level DENY ở priority 100 đã chặn trước khi traffic có cơ hội đến folder policy không? Không. Evaluation đi từ org xuống folder, không ngược lại. Nếu org có DENY rule, nó sẽ match trước folder rule.
Đây là một điểm thiết kế quan trọng: để cho phép folder override org policy, org-level rule phải dùng goto_next thay vì DENY, để delegation có thể xảy ra.
Ví dụ đúng:
Org-level policy:
priority: 100, direction: INGRESS, source: 0.0.0.0/0, port: 22, action: goto_next
priority: 200, direction: INGRESS, source: 0.0.0.0/0, port: 22, action: DENYDevelopment folder-level policy:
priority: 50, direction: INGRESS, source: "dev-office-ip/32", port: 22, action: ALLOWBây giờ:
- Traffic SSH từ office IP: match org rule priority 100 → goto_next → xuống folder policy → match priority 50 → ALLOW ✓
- Traffic SSH từ random internet IP: match org rule priority 100 → goto_next → xuống folder, không match priority 50 → xuống tiếp → match org rule priority 200 → DENY ✓
Priority range trong HFP
HFP sử dụng priority range 0 đến 2,147,483,647 — rộng hơn nhiều so với VPC firewall rules (0-65535). Điều này cho phép nhiều tầng trong hierarchy sử dụng các dải priority khác nhau mà không conflict.
Convention phổ biến:
- Org-level rules: priority 0 – 999 cho critical blocks, 100,000+ cho catch-all
goto_next - Folder-level rules: priority 1,000 – 9,999
- Project-level (network firewall policies): priority 10,000+
Secure Tags — Targeting theo attribute
HFP hỗ trợ targeting theo Secure Tags (còn gọi là Resource Manager Tags), khác với network tags của VPC firewall rules.
Secure Tags là GCP resource được quản lý bởi Resource Manager. Chúng:
- Có access control riêng (IAM trên
tagValues,tagKeys) - Không thể bị gán bởi bất kỳ user nào — chỉ những người có
tagUserrole - Có thể được defined ở org level và gán xuống resources
tagKeys:
"env" (định nghĩa ở org)
tagValues:
"production"
"development"Trong HFP rule:
targetSecureTags:
- tagValue: "tagValues/123456789" # "production"Điều này có nghĩa: chỉ VM được tagged env=production mới bị ảnh hưởng bởi rule này. Và vì việc gán tag env=production yêu cầu IAM permission riêng, không phải developer nào cũng có thể tự gán tag này cho VM của mình.
Lưu ý quan trọng: HFP không hỗ trợ network tags (những tags được gán tự do qua gcloud compute instances add-tags). Chỉ Secure Tags mới được hỗ trợ trong HFP.
Đây là một thiết kế có chủ đích: org-level security policies cần targeting cơ chế có IAM-backed access control, không phải network tags có thể bị gán tùy tiện.
Network Firewall Policies — Sibling của HFP ở Project Level
Bên cạnh Hierarchical Firewall Policies (org/folder level), GCP còn có Network Firewall Policies và Regional Network Firewall Policies ở project level. Đây là evolution của VPC firewall rules cũ với các cải tiến:
- Global Network Firewall Policy: áp dụng cho toàn bộ VPC network (không phải per-rule gắn với VPC như rules cũ)
- Regional Network Firewall Policy: chỉ áp dụng cho resources trong một region
So với VPC firewall rules legacy:
- Tương tự HFP:
goto_nextaction, Secure Tags targeting, priority range rộng hơn - Vẫn ở project level, không thể enforce xuống folder/org
Đây là bước migration: đội platform nên migrate VPC firewall rules sang Network Firewall Policies và tiến tới HFP cho org-wide rules.
Association Model — Tách Policy và Enforcement
Một điểm thiết kế quan trọng của HFP: policy resource và enforcement scope là hai thứ riêng biệt. Tạo policy chỉ tạo object; không có gì thay đổi cho đến khi bạn associate policy với một org hoặc folder.
# Bước 1: Tạo policy
gcloud compute firewall-policies create \
--organization=ORG_ID \
--short-name="baseline-security"
# Bước 2: Thêm rules vào policy
gcloud compute firewall-policies rules create \
--firewall-policy=POLICY_ID \
--priority=100 \
--direction=INGRESS \
--action=deny \
--layer4-configs=tcp:22 \
--src-ip-ranges=0.0.0.0/0
# Bước 3: Associate với org (bắt đầu enforce)
gcloud compute firewall-policies associations create \
--firewall-policy=POLICY_ID \
--organization=ORG_IDLợi thế của model này:
- Staging: tạo policy, test bằng dry-run (VPC-SC) hoặc kiểm tra bằng Connectivity Tests trước khi associate
- Atomic rollout: associate một lần cho toàn bộ org
- Reuse: một policy có thể associate với nhiều folders khác nhau
- Separation of duties: team viết policy rules vs team quyết định khi nào enforce (khác nhau)
Constraints & Failure Modes
Giới hạn scope của HFP
HFP evaluate trên tất cả networks trong scope (org hoặc folder). Không thể chỉ áp dụng HFP cho một số VPC networks nhất định trong một folder — trừ khi bạn dùng targetResources để chỉ định specific VPC networks (tính năng này chỉ có trong hierarchical policies, không có trong VPC firewall rules).
Giới hạn về egress rules trong HFP
HFP hỗ trợ cả ingress và egress rules, nhưng egress targeting phức tạp hơn. Egress rules trong HFP target destination (IP range hoặc Secure Tags của VM đích), không phải source. Khi không chắc, test bằng Connectivity Tests trong Network Intelligence Center.
"Cannot override" là không thể, không phải "khó"
Một misconception phổ biến: "nếu tôi có admin access ở project level, tôi có thể override org policy". Không thể. Về mặt kỹ thuật trong Andromeda, org-level rules được evaluate trước và một DENY terminal không có đường bypass từ tầng dưới. Đây không phải "soft enforcement" — đây là data path enforcement.
Hệ quả thực tế: nếu org policy vô tình deny một số traffic cần thiết, chỉ có org admins mới có thể fix — không phải project admins. Đây là lý do HFP cần được review cẩn thận trước khi deploy.
Policy deletion không immediate
Khi bạn dissociate hoặc delete một HFP, các rules không biến mất ngay lập tức trên tất cả VMs trong scope. Có propagation delay (eventual consistency) — trong khoảng vài giây đến vài chục giây. Trong thời gian này, rules cũ vẫn có thể còn hiệu lực.
Khi nào dùng HFP vs VPC Firewall Rules vs Network Firewall Policies
Đây là framework quyết định:
HFP tại Org level: Chỉ dùng cho security controls mà tất cả mọi người phải tuân theo và không ai được phép override. Ví dụ: block SSH/RDP từ internet trên production, deny traffic đến known malicious IP ranges, enforce ICMP restrictions. Số rules ở org level nên minimal.
HFP tại Folder level: Cho department-wide hoặc environment-wide policies mà một folder đại diện. Ví dụ: production folder có stricter rules hơn development folder.
Network Firewall Policy: Cho service-specific rules tại project level cần sharing across multiple VPCs trong project. Đây là replacement cho VPC firewall rules cũ.
VPC Firewall Rules (legacy): Chỉ dùng nếu cần backward compatibility hoặc đang trong quá trình migration. Mọi use case đều có thể migrate lên Network Firewall Policy.