This page describes how perimeter bridges can be used to allow projects and services in different service perimeters to communicate.
Before you begin
Service perimeter bridges
While a project can be assigned to only one service perimeter, you may want your project to be able to communicate with projects in another perimeter. You can enable communication to services and share data across service perimeters by creating a perimeter bridge.
A perimeter bridge allows projects in different service perimeters to communicate. Perimeter bridges are bidirectional, allowing projects from each service perimeter equal access within the scope of the bridge. However, the access levels and service restrictions of the project are controlled solely by the service perimeter that the project belongs to. A project can have multiple bridges connecting it to other projects.
A project from one service perimeter cannot indirectly gain access to projects in other perimeters. For example, assume we have three projects: A, B, and C. Each project belongs to a different service perimeter. A and B share 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 directly connected 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 to another project using a perimeter bridge.
Perimeter bridges cannot include projects from different organizations. The projects connected by a perimeter bridge must belong to service perimeters that are in the same organization.
Perimeter bridges cannot include projects from different scoped policies. Instead, you can use ingress or egress rules to allow communication between projects from different scoped policies.
After you create a perimeter bridge for a project, you cannot add the VPC networks from that project to a perimeter.
Example of perimeter bridges
For a broader example of how perimeter bridges work, consider the following setup:
The goal is to allow copies between the Cloud Storage buckets in the DMZ Perimeter and only the buckets in the Sink Project but not allow any VMs in the DMZ Perimeter access to data in Storage buckets in the Private Project.
Using the following command, a perimeter bridge (Bridge) is created, specifying that project A and project B are to be connected by the perimeter bridge.
gcloud access-context-manager perimeters create Bridge \
--title="Perimeter Bridge" --perimeter-type=bridge \
--resources=projects/12345,projects/67890
The perimeter bridge boundary is bidirectional. This means copies from DMZ Perimeter to Private Perimeter and from Private Perimeter to DMZ Perimeter are both allowed. To provide some directional control, it's best to combine perimeters with IAM permissions on the service account or identity that is executing the copy operation.