My Awesome Project

Appearance

Hierarchical Firewall Policies — Quản Lý Bảo Mật Mạng Ở Cấp Tổ Chức ​

Vấn Đề VPC Firewall Rules Không Giải Quyết Được ​

VPC firewall rules được define ở cấp VPC — điều này tạo ra vấn đề trong môi trường enterprise với nhiều VPCs, nhiều teams, nhiều projects. Bạn cần enforce baseline security policies (ví dụ: block SSH từ internet, block access đến known malicious IPs) trên tất cả VPCs trong tổ chức. Với VPC firewall rules, bạn phải:

  1. Tạo cùng rules trong mỗi VPC
  2. Duy trì consistency khi rules cần update
  3. Đảm bảo teams không override critical security rules

Hierarchical firewall policies giải quyết bài toán này bằng cách cho phép define policies ở org hoặc folder level, và tự động áp dụng cho tất cả VPCs trong hierarchy.

Internal Model: Layers Của Firewall Evaluation ​

GCP hiện tại có nhiều loại "firewall" và chúng được evaluate theo thứ tự nghiêm ngặt:

Thứ tự evaluation (từ trên xuống):

1. Hierarchical Firewall Policies (Organization level)
   ↓ nếu goto_next
2. Hierarchical Firewall Policies (Folder level - cha)
   ↓ nếu goto_next
3. Hierarchical Firewall Policies (Folder level - con)
   ↓ nếu goto_next
4. Network Firewall Policies (gắn trực tiếp với VPC)
   ↓ nếu goto_next hoặc không match
5. VPC Firewall Rules (legacy, per-VPC rules)
   ↓ nếu không match
6. Implied DENY (ingress) / ALLOW (egress)

Nguyên tắc cốt lõi: "Lower-level rules cannot override a rule from a higher place in the resource hierarchy." Một org-level rule DENY không thể bị override bởi project-level rule hay VPC firewall rule.

Tài Liệu GCP Xác Nhận ​

"Rule evaluation is hierarchical based on resource hierarchy. All rules associated with the organization are evaluated, followed by those of the first level of folders."

"Lower-level rules cannot override a rule from a higher place in the resource hierarchy."

Cơ Chế goto_next: Delegation Trong Hierarchy ​

Khác với VPC firewall rules (chỉ ALLOW hoặc DENY), hierarchical policies có action thứ ba: goto_next.

Hierarchical policy rule với action goto_next:
  "Tôi không đưa ra quyết định về packet này.
   Chuyển xuống layer thấp hơn để evaluate."

Đây là cơ chế cho phép hierarchy thực sự hoạt động:

Org policy:
  Rule 1: DENY tcp:22 từ 0.0.0.0/0 (block SSH từ internet - org-wide)
  Rule 2: goto_next (mọi thứ khác → xuống folder)

Folder policy (Production folder):
  Rule 1: DENY tcp:3306 từ 0.0.0.0/0 (block MySQL từ internet trong prod)
  Rule 2: goto_next → xuống project/VPC level

VPC Firewall Rules:
  Rule: ALLOW tcp:443 từ 0.0.0.0/0 → tag:web-server

Packet: SSH từ internet (0.0.0.0/0) → VM với tag:web-server:
  Org Rule 1: DENY tcp:22 từ 0.0.0.0/0 → MATCH → DENY ← STOP
  (không cần check Folder, VPC rules)

Packet: HTTPS từ internet → VM với tag:web-server:
  Org Rule 1: DENY tcp:22 → không match
  Org Rule 2: goto_next → xuống Folder level
  Folder Rule 1: DENY tcp:3306 → không match
  Folder Rule 2: goto_next → xuống VPC level
  VPC Rule: ALLOW tcp:443 từ 0.0.0.0/0 → tag:web-server → MATCH → ALLOW

Tại Sao goto_next Quan Trọng ​

Không có goto_next, hierarchical policy phải list tất cả traffic cần ALLOW — điều này không scalable. goto_next cho phép:

  • Org policy: Chỉ define những gì bắt buộc phải block ở mọi nơi (SSH, known malicious, compliance requirements)
  • Folder policy: Define thêm restrictions cho environment cụ thể (production stricter hơn dev)
  • VPC rules: Teams tự manage rules cho service của họ

Hierarchical Policy vs Network Firewall Policy vs VPC Firewall Rules ​

Cần phân biệt 3 loại:

Hierarchical Firewall Policy:

  • Gắn với Organization hoặc Folder
  • Evaluate trước mọi thứ khác
  • Không support network tags (chỉ service accounts và IP ranges)
  • Policies eventually consistent (có thể mất vài phút để propagate)

Network Firewall Policy:

  • Gắn trực tiếp với VPC network
  • Evaluate sau hierarchical policies nhưng trước VPC firewall rules
  • Hỗ trợ network tags và service accounts
  • Better alternative cho VPC firewall rules trong môi trường mới

VPC Firewall Rules (legacy):

  • Classic per-VPC rules
  • Evaluate cuối cùng
  • Vẫn được hỗ trợ nhưng không phải best practice cho môi trường mới

Tạo Và Quản Lý Hierarchical Policies ​

Tạo Policy Và Associate Với Org ​

bash
# Tạo policy
gcloud compute firewall-policies create \
  --short-name=org-baseline-policy \
  --description="Org-wide baseline security policy"

# Thêm rules vào policy
gcloud compute firewall-policies rules create 1000 \
  --firewall-policy=org-baseline-policy \
  --direction=INGRESS \
  --priority=1000 \
  --action=deny \
  --src-ip-ranges=0.0.0.0/0 \
  --layer4-configs=tcp:22 \
  --description="Block SSH from internet org-wide"

gcloud compute firewall-policies rules create 2000 \
  --firewall-policy=org-baseline-policy \
  --direction=INGRESS \
  --priority=2000 \
  --action=goto_next \
  --src-ip-ranges=0.0.0.0/0 \
  --layer4-configs=all \
  --description="Delegate all other traffic to lower levels"

# Associate policy với org
gcloud compute firewall-policies associations create \
  --firewall-policy=org-baseline-policy \
  --organization=<ORG_ID>

Policy Cho Production Folder ​

bash
gcloud compute firewall-policies create \
  --short-name=prod-folder-policy

# Block database ports từ internet trong production
gcloud compute firewall-policies rules create 1000 \
  --firewall-policy=prod-folder-policy \
  --direction=INGRESS \
  --action=deny \
  --src-ip-ranges=0.0.0.0/0 \
  --layer4-configs=tcp:3306,tcp:5432,tcp:27017 \
  --description="Block DB ports from internet in production"

# Allow health checks (production requirement)
gcloud compute firewall-policies rules create 500 \
  --firewall-policy=prod-folder-policy \
  --direction=INGRESS \
  --action=allow \
  --src-ip-ranges=35.191.0.0/16,130.211.0.0/22 \
  --layer4-configs=tcp:80,tcp:443,tcp:8080 \
  --description="Allow LB health checks in production"

gcloud compute firewall-policies rules create 65534 \
  --firewall-policy=prod-folder-policy \
  --direction=INGRESS \
  --action=goto_next \
  --layer4-configs=all

# Associate với Production folder
gcloud compute firewall-policies associations create \
  --firewall-policy=prod-folder-policy \
  --folder=<PROD_FOLDER_ID>

Không Thể Target Projects Trực Tiếp ​

Một constraint quan trọng: hierarchical policies không thể được associated trực tiếp với projects, chỉ với organizations hoặc folders.

Nếu muốn apply policy cho một project cụ thể mà không affect sibling projects:

  1. Tạo một folder riêng chứa chỉ project đó
  2. Gắn policy với folder đó

Hoặc dùng Network Firewall Policy (associated trực tiếp với VPC) thay vì hierarchical policy.

Eventual Consistency: Timing Quan Trọng ​

Không giống VPC firewall rules (propagate tương đối nhanh trong một VPC), hierarchical policies propagate qua toàn bộ organization và có thể mất thời gian:

"Policies are eventually consistent; hierarchy changes may take minutes to propagate."

Hệ quả cho change management:

08:00: Security team update org-level policy để block port 8443
08:00-08:05: Policy propagating qua org...

08:02: Developer test connection đến 8443 từ internet → SUCCESS (policy chưa propagate)
08:06: Developer test lại → FAIL (policy đã propagate)

→ Cửa sổ vài phút trong đó security không consistent
→ Không phải lỗi — đây là distributed system behavior

Mitigation: Với changes ảnh hưởng security, monitor propagation bằng connectivity tests từ nhiều VPCs sau khi apply policy change. Đừng assume policy có hiệu lực ngay lập tức.

IPv4 / IPv6 Không Thể Mix Trong Cùng Rule ​

Hierarchical policy rules chỉ hỗ trợ hoặc IPv4 hoặc IPv6, không thể cả hai trong cùng rule:

bash
# FAIL: không thể mix IPv4 và IPv6
gcloud compute firewall-policies rules create 1000 \
  --src-ip-ranges=0.0.0.0/0,::/0  # Lỗi

# OK: Hai rules riêng biệt
gcloud compute firewall-policies rules create 1000 \
  --src-ip-ranges=0.0.0.0/0  # IPv4

gcloud compute firewall-policies rules create 1001 \
  --src-ip-ranges=::/0  # IPv6

Design Patterns Cho Enterprise ​

Pattern 1: Org-Wide Baseline + Environment-Specific Restrictions ​

Org Policy:
├── DENY: SSH, RDP từ internet (compliance requirement)
├── DENY: Known bad IPs (threat intelligence feeds)
└── goto_next

Prod Folder Policy:
├── DENY: All database ports từ internet
├── ALLOW: Health check ranges (production specific)
└── goto_next

Dev Folder Policy:
├── ALLOW: Broader access (developers need flexibility)
└── goto_next

VPC Rules (managed by teams):
├── ALLOW: Service-specific rules
└── implied DENY/ALLOW

Pattern 2: Centralized Egress Control ​

Org Policy (Egress):
├── DENY ALL egress đến 0.0.0.0/0 (default block)
├── ALLOW egress đến 10.0.0.0/8 (internal traffic)
├── ALLOW egress đến 35.199.192.0/19 (Cloud DNS)
├── ALLOW egress đến 199.36.153.0/23 (Google APIs)
└── goto_next (allow additional egress từ lower levels)

Prod Folder Policy (Egress):
└── ALLOW egress đến approved-cdn-ips (CDN endpoints)

VPC Rules:
└── Teams không thể bypass org-level egress restrictions

Pattern này đảm bảo không có data exfiltration đến arbitrary internet destinations — một requirement quan trọng cho data-sensitive environments.

Pattern 3: Delegating Nhưng Maintaining Visibility ​

Nhiều tổ chức muốn allow teams flexibility trong security nhưng vẫn maintain visibility:

Org Policy:
├── DENY: Critical security violations (SSH, RDP from internet)
├── ALLOW-AND-LOG: Traffic đến sensitive resources (audit all access)
└── goto_next

Team policies: Full control trong constraints

ALLOW-AND-LOG behavior: policy ALLOW traffic AND tạo log entry. Teams không thể tắt logging cho critical paths ngay cả khi họ tạo override rules ở level thấp hơn.

References ​