Shared VPC — Mô Hình Mạng Tập Trung Cho Enterprise

Vấn Đề Mà Shared VPC Giải Quyết

Trong enterprise với nhiều teams, nhiều projects, hai vấn đề thường xuất hiện:

Vấn đề 1: Network sprawl — Mỗi team tạo VPC riêng, dẫn đến 50+ VPCs với CIDRs không coordinated, peering mesh phức tạp, firewall policies phân tán.

Vấn đề 2: Security governance — Khi mỗi team tự manage VPC, khó enforce org-wide network policies. Một team có thể vô tình (hoặc cố ý) tạo firewall rule expose production databases.

Shared VPC giải quyết cả hai: một team (network team) manage mạng tập trung, các teams khác deploy workloads vào mạng đó thông qua IAM-controlled access.

Internal Model: Host Project Và Service Projects

Kiến Trúc Cơ Bản

Org
└── Production Folder
    ├── Host Project "prod-network-host"          ← Network team owns
    │   └── VPC "shared-prod" (10.0.0.0/8)
    │       ├── subnet "app-subnet" (10.0.0.0/20)
    │       ├── subnet "db-subnet" (10.1.0.0/24)
    │       ├── subnet "gke-subnet" (10.2.0.0/20)
    │       └── Firewall rules, routes, Cloud NAT, etc.
    │
    ├── Service Project "team-alpha-prod"          ← Alpha team owns
    │   ├── VM instances (attached to app-subnet)
    │   ├── GKE cluster (attached to gke-subnet)
    │   └── [no VPC owned here]
    │
    └── Service Project "team-beta-prod"           ← Beta team owns
        └── VM instances (attached to app-subnet hoặc db-subnet)

Resource ownership rules:

VPCs, subnets, firewall rules, routes: Nằm trong Host project, owned bởi network team
VMs, GKE clusters, databases: Nằm trong Service projects, owned bởi application teams

Service project teams không thể modify subnets hay firewall rules trong Host project (trừ khi được granted explicit permission). Đây là toàn bộ điểm của Shared VPC.

Enable Shared VPC

bash

# Enable host project
gcloud compute shared-vpc enable prod-network-host

# Associate service projects
gcloud compute shared-vpc associated-projects add team-alpha-prod \
  --host-project=prod-network-host

gcloud compute shared-vpc associated-projects add team-beta-prod \
  --host-project=prod-network-host

IAM Model: Ai Được Access Subnet Nào

Shared VPC Admin Role

Người có compute.xpnAdmin role trên Host project (hoặc org level) có thể:

Enable/disable shared VPC
Add/remove service projects
Grant compute.networkUser role trên subnets

Thường là platform/network team leads.

Network User Role: Subnet Access

compute.networkUser role trên một subnet (hoặc toàn bộ Host project) là thứ cho phép Service project teams deploy resources vào subnet đó.

Subnet-level grant (granular):

bash

# Chỉ grant Team Alpha access vào app-subnet, không phải db-subnet
gcloud compute networks subnets add-iam-policy-binding app-subnet \
  --region=us-west1 \
  --member="group:team-alpha@company.com" \
  --role="roles/compute.networkUser"

# Team Beta chỉ có access vào db-subnet
gcloud compute networks subnets add-iam-policy-binding db-subnet \
  --region=us-west1 \
  --member="group:team-beta@company.com" \
  --role="roles/compute.networkUser"

Project-level grant (broad):

bash

# Grant access toàn bộ Host project (tất cả subnets hiện tại và tương lai)
gcloud projects add-iam-policy-binding prod-network-host \
  --member="group:all-teams@company.com" \
  --role="roles/compute.networkUser"

Tài liệu GCP xác nhận về scope của project-level grant: Granting compute.networkUser at project level "permits access to all subnets in all VPC networks of the host project, including subnets and VPC networks added in the future."

Điều này có security implication: project-level grants là "living access" — khi subnet mới được thêm vào Host project, tất cả người có project-level networkUser đều automatically có access.

Resource Creation Trong Service Projects

Khi Team Alpha tạo VM trong Service project team-alpha-prod:

bash

# Team Alpha tạo VM và specify subnet từ Host project
gcloud compute instances create alpha-web-server \
  --project=team-alpha-prod \
  --zone=us-west1-a \
  --machine-type=n2-standard-4 \
  --subnet=projects/prod-network-host/regions/us-west1/subnetworks/app-subnet

VM object tồn tại trong team-alpha-prod, nhưng:

Primary IP được cấp từ app-subnet (owned bởi prod-network-host)
VM tham gia vào VPC networking của prod-network-host
Firewall rules của prod-network-host áp dụng cho VM

Tài liệu GCP về resource ownership: "Resources are created in service projects but consume address space from host project subnets."

Static Internal IP Addresses

Nếu Team Alpha cần static internal IP cho một service:

bash

# Static IP object được tạo trong SERVICE project
gcloud compute addresses create alpha-api-static-ip \
  --project=team-alpha-prod \
  --region=us-west1 \
  --subnet=projects/prod-network-host/regions/us-west1/subnetworks/app-subnet

# IP được reserved trong Host project's subnet nhưng object ở Service project

Tài liệu GCP: "The internal IPv4 or IPv6 address object must be created in the same service project as the resource that uses it, even though the value of the IP address comes from available IP addresses of the shared subnet."

Điều này tạo ra một sự phân chia thú vị: IP object ở Service project, nhưng actual IP đến từ Host project subnet.

DNS Trong Shared VPC

Shared VPC có behavior DNS đặc biệt — đây là một điểm gây confusion.

VMs trong cùng Service project có thể resolve nhau qua Compute Engine internal DNS:

vm-1.c.team-alpha-prod.internal → resolve thành công

VMs trong khác Service project KHÔNG thể resolve nhau qua Compute Engine DNS by default:

# Từ team-alpha-prod VM:
nslookup vm-beta.c.team-beta-prod.internal → NXDOMAIN

Tài liệu GCP: "VMs in the same service project can reach each other using the internal DNS names that Google Cloud creates automatically. These DNS names use the project ID of the service project."

Giải pháp cho cross-service-project DNS: Tạo shared private DNS zones trong Host project:

bash

# Tạo DNS zone trong Host project, accessible bởi tất cả service project VMs
gcloud dns managed-zones create shared-services-zone \
  --project=prod-network-host \
  --dns-name=shared.internal. \
  --visibility=private \
  --networks=projects/prod-network-host/global/networks/shared-prod

# Tất cả services đăng ký DNS records trong zone này
# api.shared.internal → team-alpha VMs
# data.shared.internal → team-beta VMs

Approach này cho phép service discovery cross-service-project thông qua stable DNS names.

Billing Attribution

Billing rule: Billing cho resource được attributed cho project chứa resource đó, không phải Host project.

VM trong team-alpha-prod:
  Compute cost → team-alpha-prod billing account
  Egress bandwidth cost → team-alpha-prod

VM trong team-beta-prod:
  Compute cost → team-beta-prod billing account

VPC, Subnets trong prod-network-host:
  VPC costs (routes, etc.) → prod-network-host
  Cloud NAT (nếu có) → prod-network-host
  Cloud VPN → prod-network-host

Điều này cho phép chargeback model tốt: mỗi team trả cho workloads của họ, network team trả cho shared infrastructure.

Tài liệu GCP: "Billing for resources that participate in a Shared VPC network is attributed to the service project where the resource is located."

Constraints Kỹ Thuật Quan Trọng

Một Host Project Per Service Project

Service project chỉ có thể attach vào MỘT host project tại một thời điểm.
Không thể có VM trong team-alpha-prod kết nối vào VPC của prod-network-host
VÀ VPC của prod-network-host-2 cùng lúc.

Nếu team cần access nhiều VPCs, phải dùng VPC Peering (giữa các Host VPCs) hoặc NCC.

Host Project Không Thể Là Service Project

A project cannot be both a host project and a service project simultaneously.

Nếu cần làm host cho team khác, project đó không thể join Shared VPC của project khác.

Firewall Rules Location

Có thể tạo firewall rules trong cả Host project lẫn Service project:

Host project firewall rules: Áp dụng cho tất cả VMs trong Shared VPC (cả host và service projects)
Service project firewall rules: Chỉ áp dụng cho VMs trong service project đó

Wait — Service project teams CÓ THỂ tạo VPC firewall rules? Có, nhưng:

Họ phải được grant compute.securityAdmin hoặc tương đương trên Host project
Hoặc tạo rules áp dụng cho instances của họ trong scope của service project

Best practice: Network team manage tất cả firewall rules trong Host project. Service project teams chỉ có read access vào firewall rules.

Shared VPC Và GKE: Coordination Requirements

GKE trong Shared VPC cần coordination phức tạp hơn:

bash

# GKE SA trong Service project cần permission trong Host project
gcloud projects add-iam-policy-binding prod-network-host \
  --member="serviceAccount:service-<SERVICE_PROJECT_NUMBER>@container-engine-robot.iam.gserviceaccount.com" \
  --role="roles/container.hostServiceAgentUser"

# Tạo GKE cluster với subnet từ Host project
gcloud container clusters create alpha-cluster \
  --project=team-alpha-prod \
  --region=us-west1 \
  --network=projects/prod-network-host/global/networks/shared-prod \
  --subnetwork=projects/prod-network-host/regions/us-west1/subnetworks/gke-subnet \
  --cluster-secondary-range-name=gke-pods \
  --services-secondary-range-name=gke-services

Secondary ranges cho pods và services phải được defined trong Host project's subnet, nhưng GKE cluster (và pods) belong to Service project.

Pattern: Hub-and-Spoke Với Shared VPC

Host Project (Network Hub):
  VPC shared-vpc
    ├── Subnets per region
    ├── Cloud NAT (shared egress)
    ├── Cloud VPN/Interconnect (hybrid connectivity)
    ├── Private Service Connect endpoints (access Google APIs)
    └── Centralized DNS zones

Service Projects (Spokes):
  ├── team-alpha: Web applications (app-subnet)
  ├── team-beta: Data processing (compute-subnet)
  ├── team-gamma: ML workloads (gpu-subnet)
  └── team-delta: Database services (db-subnet)

Benefits:
  → Tất cả egress đi qua centralized NAT (logging, visibility)
  → On-premises accessible từ tất cả teams qua một Interconnect
  → DNS service discovery tập trung
  → Firewall governance tập trung

Khi Nào Dùng Shared VPC vs VPC Peering vs Separate VPCs

Scenario	Recommendation
Teams có shared network requirements, central governance	Shared VPC
Two independent teams need occasional connectivity	VPC Peering
Complete isolation required (compliance, multi-tenant)	Separate VPCs
Large org, many teams, scale > 25 VPCs	Shared VPC + NCC
Small org, few teams, temporary connection	VPC Peering

References

Shared VPC Overview — Tài liệu chính thức
Provisioning Shared VPC — Hướng dẫn thiết lập
IAM for Shared VPC — IAM roles và permissions
GKE with Shared VPC — GKE integration
Shared VPC Quotas — Limits và quotas

Shared VPC — Mô Hình Mạng Tập Trung Cho Enterprise ​

Vấn Đề Mà Shared VPC Giải Quyết ​

Internal Model: Host Project Và Service Projects ​

Kiến Trúc Cơ Bản ​

Enable Shared VPC ​

IAM Model: Ai Được Access Subnet Nào ​

Shared VPC Admin Role ​

Network User Role: Subnet Access ​

Resource Creation Trong Service Projects ​

Static Internal IP Addresses ​

DNS Trong Shared VPC ​

Billing Attribution ​

Constraints Kỹ Thuật Quan Trọng ​

Một Host Project Per Service Project ​

Host Project Không Thể Là Service Project ​

Firewall Rules Location ​

Shared VPC Và GKE: Coordination Requirements ​

Pattern: Hub-and-Spoke Với Shared VPC ​

Khi Nào Dùng Shared VPC vs VPC Peering vs Separate VPCs ​

References ​

Shared VPC — Mô Hình Mạng Tập Trung Cho Enterprise

Vấn Đề Mà Shared VPC Giải Quyết

Internal Model: Host Project Và Service Projects

Kiến Trúc Cơ Bản

Enable Shared VPC

IAM Model: Ai Được Access Subnet Nào

Shared VPC Admin Role

Network User Role: Subnet Access

Resource Creation Trong Service Projects

Static Internal IP Addresses

DNS Trong Shared VPC

Billing Attribution

Constraints Kỹ Thuật Quan Trọng

Một Host Project Per Service Project

Host Project Không Thể Là Service Project

Firewall Rules Location

Shared VPC Và GKE: Coordination Requirements

Pattern: Hub-and-Spoke Với Shared VPC

Khi Nào Dùng Shared VPC vs VPC Peering vs Separate VPCs

References