VPC Service Controls — Perimeter Security Orthogonal với IAM
Tại sao VPC-SC tồn tại khi đã có IAM
IAM kiểm soát "who can do what" — identity-based access control. Nhưng IAM không thể trả lời câu hỏi: "Tôi muốn đảm bảo rằng data trong project production của tôi chỉ được access từ trong mạng nội bộ của công ty, kể cả khi có đủ IAM permissions". IAM không có concept về "context" của request — nó không biết request đến từ corporate network hay từ một máy tính bị compromise ở đâu đó trên internet.
VPC Service Controls (VPC-SC) giải quyết data exfiltration risk — nguy cơ data bị copy ra ngoài perimeter tổ chức, kể cả bởi người có legitimate IAM permissions.
Một kịch bản cụ thể: alice@example.com có roles/bigquery.dataViewer trên dataset chứa customer PII. Alice làm việc từ laptop cá nhân ở nhà, download toàn bộ dataset về máy tính cá nhân. IAM cho phép điều này vì alice có đúng role. VPC-SC có thể block điều này bằng cách restrict BigQuery API access chỉ từ trong corporate VPN/network.
VPC-SC không phải Firewall, không phải IAM
Điều quan trọng nhất cần hiểu về VPC-SC: nó enforce ở API layer (application layer), không phải network layer như firewall.
Request từ client
│
▼
[Internet / Private Network]
│
▼
┌─────────────────────────────────────┐
│ GCP Edge / GFE (L7 proxy) │
│ → HTTPS termination │
│ → Identity verification │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ VPC Service Controls │ ← Enforce ở đây
│ → Perimeter check │
│ → Access level evaluation │
│ → Ingress/egress rules │
└─────────────────────────────────────┘
│ (nếu pass)
▼
┌─────────────────────────────────────┐
│ IAM (PAB → Deny → Allow) │ ← IAM sau VPC-SC
└─────────────────────────────────────┘
│ (nếu authorized)
▼
┌─────────────────────────────────────┐
│ GCP Service (GCS, BigQuery...) │
└─────────────────────────────────────┘VPC-SC chặn ở tầng API gateway — tức là request đã arrive ở GCP infrastructure nhưng chưa được process bởi service. Không giống firewall (chặn connection ở network level), VPC-SC cho phép TCP connection establish nhưng chặn API call sau khi evaluate context.
Perimeter concept: Tạo boundary xung quanh resources
Một service perimeter định nghĩa một nhóm GCP projects và services tạo thành một "trusted zone". Traffic bên trong perimeter có thể access resource tự do; traffic từ ngoài vào bị chặn trừ khi có explicit exception.
┌─────────────────────────────────────────────────┐
│ Service Perimeter "production" │
│ │
│ ┌─────────────────┐ ┌─────────────────────┐ │
│ │ Project A │ │ Project B │ │
│ │ (analytics) │ │ (data-pipeline) │ │
│ │ │ │ │ │
│ │ BigQuery │ │ Dataflow jobs │ │
│ └─────────────────┘ └─────────────────────┘ │
│ │
│ Services protected: bigquery.googleapis.com │
│ storage.googleapis.com │
└─────────────────────────────────────────────────┘
↑
│ Blocked by default
│
External requests
(kể cả từ project khác trong cùng org)Bên trong perimeter, mọi request giữa các projects và services được phép (plus IAM check vẫn apply). Từ bên ngoài perimeter, requests bị chặn bởi VPC-SC, kể cả người có đủ IAM permissions.
Hai loại perimeter
Standard Perimeter: Tạo boundary đơn giản — bên trong và bên ngoài. Communication xuyên perimeter bị chặn trừ khi có ingress/egress rules.
Perimeter Bridge (legacy): Cho phép communication giữa hai perimeters riêng biệt. Nay được thay thế bởi ingress/egress rules (granular hơn và dễ audit hơn).
Access Levels: Định nghĩa "ai được vào từ ngoài"
Access levels là conditions được định nghĩa trong Access Context Manager — một service riêng quản lý context-based access policies. Chúng định nghĩa những attributes của request khiến request được coi là "trusted" dù đến từ ngoài perimeter.
Các attributes có thể dùng trong access levels:
- IP range: Request phải đến từ dải IP cụ thể (ví dụ: corporate VPN IP range)
- Geographic location: Request phải đến từ country/region cụ thể
- Device policies: Request phải từ device đăng ký trong corporate MDM (BeyondCorp)
- Principal identity: Chỉ cho phép specific users/groups kể cả từ ngoài perimeter
# Tạo access level "corporate network only"
gcloud access-context-manager levels create CORP_NETWORK \
--title="Corporate Network" \
--basic-level-spec='ipSubnetworks:
- 203.0.113.0/24
- 198.51.100.0/24'Ingress và Egress Rules: Granular exceptions
Ingress và egress rules cho phép define exceptions cụ thể cho perimeter, thay vì "tất cả hoặc không có gì".
Ingress Rules
Cho phép external requests vào perimeter dựa trên:
- Identity của caller (user, SA)
- Source network (VPC, IP range)
- Target service và API method
# Ví dụ: Cho phép CI/CD pipeline từ bên ngoài truy cập GCS trong perimeter
ingressPolicies:
- ingressFrom:
identities:
- serviceAccount:cicd-deployer@cicd-project.iam.gserviceaccount.com
sources:
- resource: projects/cicd-project
ingressTo:
operations:
- serviceName: storage.googleapis.com
methodSelectors:
- method: google.storage.v2.Storage.WriteObject
resources:
- projects/123456789Egress Rules
Cho phép resources bên trong perimeter gọi API hoặc access data bên ngoài perimeter:
# Ví dụ: Cho phép BigQuery job export data sang GCS bucket ở ngoài perimeter
egressPolicies:
- egressFrom:
identities:
- serviceAccount:bq-export-sa@analytics-project.iam.gserviceaccount.com
egressTo:
operations:
- serviceName: storage.googleapis.com
methodSelectors:
- method: google.storage.v2.Storage.WriteObject
resources:
- projects/456789012 # project với export bucket, ngoài perimeterVPC-SC và IAM: Hai lớp bổ sung, không thay thế nhau
Một điểm cần nhấn mạnh: VPC-SC không thay thế IAM, nó bổ sung IAM. Ngay cả khi một request pass qua VPC-SC perimeter, IAM vẫn được evaluate. Một request cần pass cả hai:
- VPC-SC: Request đến từ context được phép (inside perimeter hoặc có valid access level)
- IAM: Principal có đủ permissions
VPC-SC allows + IAM denies → Request bị từ chối (IAM 403)
VPC-SC denies + IAM allows → Request bị từ chối (VPC-SC 403 với VPCSC violation)
VPC-SC allows + IAM allows → Request thành côngError từ VPC-SC violation có format đặc biệt trong error response:
{
"error": {
"code": 403,
"message": "Request is prohibited by organization's policy. vpcServiceControls",
"status": "PERMISSION_DENIED",
"details": [
{
"@type": "type.googleapis.com/google.rpc.ErrorInfo",
"reason": "SECURITY_POLICY_VIOLATED",
"domain": "googleapis.com",
"metadata": {
"uid": "...",
"violationReason": "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
}
}
]
}
}Dry-run mode: Tránh break production khi implement
VPC-SC có dry-run mode — cho phép test policy mà không thực sự enforce. Khi enable, violations được log nhưng requests vẫn được phép.
# Enable dry-run cho một perimeter
gcloud access-context-manager perimeters update PERIMETER_ID \
--policy=POLICY_ID \
--enable-restriction-mode=DRY_RUN
# Kiểm tra dry-run violations trong logs
gcloud logging read \
'logName:"cloudaudit.googleapis.com%2Fpolicy"
AND protoPayload.metadata.dryRun=true'Workflow khuyến nghị khi implement VPC-SC trong production environment đã tồn tại:
- Enable dry-run trên perimeter
- Monitor violations trong 2-4 tuần để identify legitimate traffic cần ingress/egress rules
- Tạo ingress/egress rules cho legitimate patterns
- Switch sang enforcement mode
- Monitor enforcement violations để catch bất kỳ case nào bị bỏ sót
Restricted.googleapis.com: VPC-SC và Private Google Access
Khi workload trong VPC cần access Google APIs qua private network (Private Google Access), có hai virtual IP options:
- private.googleapis.com (199.36.153.8/30): Access Google APIs không qua internet, nhưng không enforce VPC-SC
- restricted.googleapis.com (199.36.153.4/30): Access Google APIs không qua internet, enforce VPC-SC
Nếu organization dùng VPC-SC, workloads trong protected perimeter nên route API calls qua restricted.googleapis.com:
# Route traffic đến restricted endpoint qua DNS
# Trong Cloud DNS, tạo private zone cho googleapis.com
# với CNAME hoặc A records trỏ đến 199.36.153.4-7Nếu workload dùng private.googleapis.com, họ bypass VPC-SC enforcement ngay cả khi đang ở trong VPC — một misconception phổ biến dẫn đến security gap.
VPC-SC trong bức tranh tổng thể access control
VPC-SC được đề cập trong Chapter này (IAM Deep Dive) vì nó là một trong các lớp access control trong GCP, nhưng phân tích đầy đủ về VPC-SC architecture, perimeter types, và service perimeter design đã được trình bày ở:
- Chapter 27 - Network Security: VPC Service Controls Perimeter
- Chapter 19 - VPC Routing: VPC Service Controls Perimeter (IAM angle)
File này tập trung vào vị trí của VPC-SC trong IAM evaluation pipeline và sự khác biệt về cơ chế so với IAM.