Sharing across perimeters with bridges

This page describes how perimeter bridges can be used to allow projects andservices in different service perimeters to communicate.

Before you begin

Service perimeter bridges

While a project can be assigned to only one service perimeter, youmay want your project to be able to communicate with projects in anotherperimeter. You can enable communication to services and share data acrossservice perimeters bycreating aperimeter bridge.

A perimeter bridge allows projects in different service perimeters tocommunicate. Perimeter bridges are bidirectional, allowing projects from eachservice perimeter equal access within the scope of the bridge. However, theaccess levels and service restrictions of the project are controlled solely bythe service perimeter that the project belongs to. A project can have multiplebridges connecting it to other projects.

A project from one service perimeter cannot indirectly gain access to projectsin other perimeters. For example, assume we have three projects: A, B,and C. Each project belongs to a different service perimeter. A and Bshare a perimeter bridge. B and C also share a bridge.While data can move between A and B, as well as between B and C,nothing can pass between A and C because the two projects are not directlyconnected by a perimeter bridge.

Considerations

Before you create a perimeter bridge, consider the following:

  • A project must belong to a service perimeter before it can be connected toanother project using a perimeter bridge.

  • Perimeter bridges cannot include projects from different organizations.The projects connected by a perimeter bridge must belong to serviceperimeters that are in the same organization.

  • Perimeter bridges cannot include projects from differentscopedpolicies. Instead, you canuseingress or egress rulesto allow communication between projects from different scoped policies.

  • After you create a perimeter bridge for a project, you cannot add theVPC networks from that project to a perimeter.

Example of perimeter bridges

For a broader example of how perimeter bridges work, consider the followingsetup:

Perimeter bridge access diagram

The goal is to allow copies between the Cloud Storage buckets inthe DMZ Perimeter and only the buckets in the Sink Project but not allowany VMs in the DMZ Perimeter access to data in Storage buckets in thePrivate Project.

Using the following command, a perimeter bridge (Bridge) is created,specifying that project A and project B are to be connected by theperimeter bridge.

Note: In the example command and the previous diagram, projects A and B arerepresented by their project numbers, 12345 and 67890, as the project numbersare required for theresources option.
gcloudaccess-context-managerperimeterscreateBridge\--title="Perimeter Bridge"--perimeter-type=bridge\--resources=projects/12345,projects/67890

The perimeter bridge boundary is bidirectional. This means copies fromDMZ Perimeter to Private Perimeter and from Private Perimeter toDMZ Perimeter are both allowed. To provide some directional control,it's best to combine perimeters with IAM permissions on theservice account or identity that is executing the copy operation.

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2026-02-19 UTC.