VPC Service Controls Integration với GCS

Tại Sao Quan Trọng Trong Production

IAM kiểm soát ai được làm gì với GCS. VPC Service Controls (VPC-SC) kiểm soát từ đâu request đến GCS được chấp nhận — kể cả khi principal đã có IAM permission. Đây là layer bổ sung thứ ba sau IAM và network controls, và là cơ chế duy nhất ngăn data exfiltration qua GCS từ trong GCP network. Không có VPC-SC, một service account bị compromise trong VPC của bạn có thể copy data sang bucket của attacker.

---

Internal Model — VPC-SC Ở API Layer

GCS Là API Service, Không Phải Network Resource

Firewall rules và VPC controls hoạt động ở network layer (IP, port). Nhưng GCS là một managed service — không có IP endpoint nằm trong VPC của bạn. Mọi request đến GCS đều đi ra Google's public API infrastructure.

VPC-SC giải quyết vấn đề này bằng cách operate ở API layer: thay vì chặn ở network level, VPC-SC chặn ở IAM/authentication evaluation của API server.

Không có VPC-SC:
  VM trong VPC → internet → GCS API → IAM check → ALLOW/DENY

Với VPC-SC:
  VM trong VPC → internet → GCS API → IAM check → VPC-SC check → ALLOW/DENY
                                                         ↑
                                   VPC-SC verify: request đến từ đâu?
                                   Có nằm trong perimeter không?

Service Perimeter — Boundary Của Bảo Vệ

VPC-SC tạo ra service perimeter — một virtual boundary xung quanh một tập GCP resources (projects, services). Khi một service (như storage.googleapis.com) được đưa vào perimeter, requests đến service đó từ ngoài perimeter bị chặn mặc định.

Perimeter "production-perimeter":
  Projects: [project-a, project-b]
  Services: [storage.googleapis.com, bigquery.googleapis.com]

Hệ quả:
  ✓ VM trong project-a → GCS bucket trong project-a: ALLOW
  ✓ VM trong project-b → GCS bucket trong project-a: ALLOW (same perimeter)
  ✗ VM trong project-c → GCS bucket trong project-a: DENY (outside perimeter)
  ✗ Developer laptop (internet) → GCS bucket trong project-a: DENY (unless Access Level)

Restricted VIP — Private Access Cho GCS

Khi VMs trong VPC truy cập GCS, traffic thông thường đi ra internet (dù GCS là Google service). Để giữ traffic trong Google network và enforce VPC-SC policies, dùng restricted Virtual IP (VIP).

GCS có hai private VIP ranges:

• Private VIP (199.36.153.8/30): Cho Private Google Access — giữ traffic trong Google network nhưng không enforce VPC-SC
• Restricted VIP (199.36.153.4/30): Enforce VPC-SC policies — bắt buộc nếu muốn VPC-SC work đúng

# Cấu hình DNS trong VPC để route *.storage.googleapis.com qua restricted VIP
# Cloud DNS private zone:
storage.googleapis.com → CNAME → restricted.googleapis.com
restricted.googleapis.com → A → 199.36.153.4
                                 199.36.153.5
                                 199.36.153.6
                                 199.36.153.7

Nếu VM dùng public IP của GCS thay vì restricted VIP, requests bypass VPC-SC → data exfiltration vẫn possible.

Đây là một critical misconfiguration pattern: team setup VPC-SC nhưng không configure DNS routing qua restricted VIP → VPC-SC không có hiệu lực cho GCS access từ VMs.

Access Levels — Exceptions Cho Trusted Contexts

VPC-SC mặc định chặn tất cả access từ ngoài perimeter. Access Levels define trusted contexts được exempt:

Access Level "corporate-network":
  IP ranges: [203.0.113.0/24]  # corporate office IPs
  
Access Level "admin-users":
  Identity: [admin@company.com]
  
Ingress rule:
  From: accessLevel "corporate-network"
  To: buckets trong perimeter
  Operations: storage.objects.get

Access Levels có thể based trên:

• IP range
• Identity (specific users/service accounts)
• Device attributes (corporate-managed devices với Endpoint Verification)
• Time constraints

Ingress và Egress Rules — Bidirectional Control

VPC-SC 2.0 (current) có ingress rules và egress rules thay vì chỉ perimeter isolation đơn giản.

Ingress rules — cho phép traffic vào perimeter từ ngoài:

{
  "ingressPolicies": [
    {
      "ingressFrom": {
        "sources": [
          {
            "accessLevel": "accessPolicies/POLICY/accessLevels/corp-network"
          }
        ],
        "identities": ["serviceAccount:etl-sa@project.iam.gserviceaccount.com"]
      },
      "ingressTo": {
        "resources": ["projects/123456789"],
        "operations": [
          {
            "serviceName": "storage.googleapis.com",
            "methodSelectors": [
              { "method": "google.storage.v1.Storage.GetObject" }
            ]
          }
        ]
      }
    }
  ]
}

Egress rules — cho phép traffic ra từ perimeter:

{
  "egressPolicies": [
    {
      "egressFrom": {
        "identities": ["serviceAccount:backup-sa@project.iam.gserviceaccount.com"]
      },
      "egressTo": {
        "resources": ["projects/BACKUP_PROJECT"],
        "operations": [
          {
            "serviceName": "storage.googleapis.com",
            "methodSelectors": [{ "permission": "storage.objects.create" }]
          }
        ]
      }
    }
  ]
}

Egress rules là cơ chế ngăn data exfiltration: nếu backup-sa bị compromise, attacker chỉ có thể copy data đến BACKUP_PROJECT (nằm trong egress whitelist), không thể copy đến arbitrary external bucket.

---

Constraints & Operational Considerations

VPC-SC Không Thay Thế IAM

VPC-SC là layer bổ sung, không thay thế IAM. Cả hai phải pass:

Request → IAM check → VPC-SC check → access

IAM deny → blocked (VPC-SC không được evaluate)
IAM allow → VPC-SC deny → blocked
IAM allow → VPC-SC allow → access granted

Điều này nghĩa là VPC-SC không thể grant quyền mà IAM không có — nó chỉ có thể thêm restrictions.

Dry-Run Mode — Kiểm Tra Trước Khi Enforce

VPC-SC hỗ trợ dry-run mode (audit mode): rules được evaluate nhưng không enforce — violations được log vào Cloud Audit Logs.

# Tạo perimeter ở dry-run mode
gcloud access-context-manager perimeters create my-perimeter \
  --policy=POLICY_ID \
  --resources=projects/123 \
  --restricted-services=storage.googleapis.com \
  --perimeter-type=regular

# Enforce sau khi verify logs
gcloud access-context-manager perimeters update my-perimeter \
  --policy=POLICY_ID \
  --enable-vpc-accessible-services

Luôn chạy dry-run trước khi enforce trên production — VPC-SC misconfiguration có thể block legitimate access và gây outage.

Interaction Với Transfer Service

Cloud Storage Transfer Service chạy từ Google infrastructure, không phải từ VPC của customer. Điều này nghĩa là nếu source hoặc destination bucket nằm trong VPC-SC perimeter, phải add Transfer Service service account vào ingress/egress rules:

Transfer Service SA: service-PROJECT_NUMBER@gcp-sa-datatransfer.iam.gserviceaccount.com

Interaction Với Cloud Functions / Cloud Run

Serverless services (Cloud Functions, Cloud Run) không tự động nằm trong perimeter. Để serverless functions access GCS trong perimeter, cần:

1. Serverless function nằm trong VPC Connector connected đến perimeter VPC
2. Add function's service account vào ingress rules
3. Route traffic qua Private Google Access

---

Anti-Patterns

Anti-Pattern: Public API Endpoint Bypass VPC-SC

Team configure VPC-SC cho storage.googleapis.com
VM trong VPC dùng public DNS → resolve tới public GCS IPs
→ Traffic đi ra internet → bypass VPC-SC enforce
→ VPC-SC vô hiệu

Fix: Configure Cloud DNS private zone redirect *.googleapis.com sang restricted VIP. Verify với nslookup storage.googleapis.com từ trong VM.

Anti-Pattern: Quên Egress Rules Cho Cross-Project Operations

Pipeline trong project A cần write sang GCS bucket trong project B
Project A trong perimeter, project B ngoài perimeter
→ Không có egress rule → write bị chặn
→ Pipeline fail với "Request is prohibited by organization's policy"

Fix: Thêm egress rule cho SA của pipeline, allow write đến project B.

---

References

• VPC Service Controls Overview
• VPC-SC for Cloud Storage
• Restricted Virtual IP
• Ingress and Egress Rules