VPC SC: Bridges and Ingress/Egress Rules

Advanced VPC Service Controls (VPC SC)

While a single perimeter provides a strong boundary, real-world enterprise architectures often require data to move securely between different departments, organizations, or perimeters. Perimeter Bridges and Ingress/Egress Rules are the tools used to manage these complex interactions without compromising security.

For a Professional Cloud Security Engineer (PSE), mastering these concepts is critical for designing scalable, multi-perimeter architectures that support collaboration while preventing data exfiltration.

白話文解釋（Plain English Explanation）

VPC SC bridges and ingress/egress rules can feel abstract until you map them onto everyday boundaries. Three analogies make the trade-offs stick.

Analogy 1: Office Building Security Doors (Perimeter Bridge)

Imagine two locked office floors — HR on floor 3, Finance on floor 4 — each protected by a badge reader. A Perimeter Bridge is like installing a permanent connecting door between the two floors: once it exists, every HR employee can walk into Finance, and every Finance employee can walk into HR. There is no per-person check, no per-room restriction, and the door swings both ways. That is why GCP describes bridges as bidirectional and symmetric — and why the platform caps you at 10 bridges per regular perimeter. Bridges are a coarse trust statement, not a surgical access control.

Analogy 2: Airport Customs (Ingress and Egress Rules)

Now picture an international airport. Ingress rules are the immigration officers at the arrival gate of Perimeter_HR: they check from.identities (which passport — e.g. a specific analytics-svc@…iam.gserviceaccount.com), inspect from.sources.accessLevel (which country you flew in from — a trusted Access Context Manager level), and only then stamp to.operations (which terminal/API — storage.googleapis.com with method google.storage.objects.get) on to.resources (which specific GCS bucket). Egress rules are customs officers at departure in Perimeter_Finance: they decide whether your service account is allowed to carry data out to to.externalResources such as projects/hr-prod or a Service Directory endpoint. Both sides must independently agree, exactly like an exit visa plus an entry visa.

Analogy 3: Diplomatic Pouch vs Open Border (Bridge vs Regular Perimeter)

A Regular perimeter is a sovereign country with its own borders — full Access Levels, ingress/egress policies, dry-run mode, and protected services. A Bridge perimeter is more like a diplomatic pouch route between two countries: it carries no policies of its own, only declares "these two regular perimeters trust each other in bulk." You cannot put Access Levels on a bridge, you cannot enforce dry-run on a bridge, and you cannot restrict the bridge to a single bucket. When the audit team asks "exactly which identity touched which resource?", a bridge gives you nothing — that is why Google's own guidance steers new deployments toward ingress/egress rules.

Configuring Perimeter Bridges

A Perimeter Bridge allows projects in different service perimeters to communicate.

How it Works:

• You "link" two perimeters by creating a bridge.
• Projects within Perimeter A can now call restricted services in Perimeter B, and vice-versa.
• The bridge is bi-directional and all-or-nothing (all projects in A can talk to all projects in B).

Advanced Ingress and Egress Rules

Ingress and Egress rules provide fine-grained control over what traffic can enter or leave a perimeter.

Ingress Rules (Who can come in?)

An Ingress rule defines:

1. From: The source (Access Level, specific project, or identity).
2. To: The destination (Protected project and specific services/APIs).

Egress Rules (Who can go out?)

An Egress rule defines:

1. From: The source (Identity or project inside the perimeter).
2. To: The destination (External project, service, or resource).

Moving Resources Between Perimeters

Moving a project from Perimeter A to Perimeter B (or removing it entirely) is a high-risk operation.

1. Dependency Check: Ensure the project doesn't have active dependencies on other projects in the current perimeter.
2. Dry-run Mode: Use dry-run mode to see what will break before making the move.
3. Timing: Changes to perimeters can take up to 30 minutes to propagate.

Shared VPC Scenarios with VPC SC

In a Shared VPC setup, the Host Project and the Service Projects must be handled carefully.

• Rule: The Host Project and all its Service Projects must be in the same service perimeter.
• If you place them in different perimeters, communication over the VPC network (like internal IPs) will still work, but calls to Google APIs (like GCS) will be blocked by VPC SC unless bridges or rules are in place.

Hybrid Access to Restricted Services

Private Google Access (PGA) allows on-premises systems to reach Google APIs over a VPN or Interconnect.

• When VPC SC is involved, PGA traffic must be explicitly allowed.
• You must create an Access Level based on the on-premises IP ranges and include it in the perimeter's Ingress policy.

Scoping Rules by Identity and Resource

Unlike bridges, Ingress/Egress rules allow you to specify exactly which service account can access which specific bucket.

• Example: Only the [email protected] can read from gs://sensitive-data-bucket in Project B.

Best Practices for Multi-Perimeter Architecture

1. Avoid Perimeter Fragmentation: Creating too many small perimeters leads to "rule fatigue" and complexity. Group projects with similar data sensitivity together.
2. Use Folder-Level Policies: Manage perimeters at the folder level for easier administration in large organizations.
3. Standardize Rules: Use consistent naming and logic for Access Levels across the organization.

Managing VPC SC in a CI/CD Pipeline

Automated deployments (like Terraform or Jenkins) often fail when VPC SC is first turned on.

• The Fix: Add the CI/CD service account to an Ingress Rule.
• Identity-based Ingress: Explicitly allow the [email protected] identity to bypass the perimeter for management tasks.

Complex Data Sharing Patterns

Scenario: The Data Clean Room

Two companies (Company A and Company B) want to share data for analysis without either side seeing the raw data.

1. Create a Data Clean Room Perimeter.
2. Company A creates an Egress Rule to push data to the clean room.
3. Company B creates an Egress Rule to push data to the clean room.
4. The analysis results are sent out via a separate rule, but the raw data never leaves the clean room perimeter.

PSE Exam Scenarios

Scenario 1: Fine-Grained Cross-Perimeter Access

"A company has two perimeters: Perimeter_HR and Perimeter_Finance. A service account in Finance needs to read one specific file from an HR bucket. What is the most secure way?" Answer: Create an Ingress Rule in Perimeter_HR that specifies the Finance service account as the "From" and the specific bucket as the "To". Create an Egress Rule in Perimeter_Finance that allows that service account to reach the HR project.

Scenario 2: Shared VPC and VPC SC

"You are moving a Service Project into a perimeter, but the Host Project is in a different perimeter. What will happen?" Answer: The movement will likely cause API calls to fail. According to Google Cloud best practices, the Host and Service projects should reside in the same perimeter. If they must be separate, complex Ingress/Egress rules are required for every API interaction.

Summary Checklist

• Contrast Perimeter Bridges with Ingress/Egress rules.
• List the components of an Ingress rule (From/To).
• Explain why Shared VPC projects should be in the same perimeter.
• Describe how to allow on-premises access to a perimeter.
• Understand the "Clean Room" data sharing pattern.