You can share Google Cloud Platform (GCP) virtual networks across projects in your Cloud Organization. This capability is referred to as Cross-Project Networking (XPN).
In large organizations, you may need to put different departments or different applications into different projects for purposes of separating budgeting, access control, and so on. With XPN, Cloud Organization administrators can give multiple projects permission to use a single, shared virtual network and corresponding networking resources.
XPN allows creation of a virtual network of RFC1918 IP spaces that associated projects can then use. Admins in associated projects can create virtual machine (VM) instances in the shared network spaces. Network and security admins can create VPNs and firewall rules usable by all the projects in the network. Consistent policies can be applied and enforced easily across a Cloud Organization.
Concepts and terminology
The following concepts and terminology are useful when understanding the purpose and scope of XPN:
- XPN host project — Project that hosts sharable networking resources within a Cloud Organization. The shared networking resources can be used by other departments (contained in separate XPN service projects) in the Cloud Organization. An XPN host project can have several XPN service projects associated with it. You can define which resources can be referenced by other projects and which resources are constrained within a specific project.
- XPN service project (also referred to as XPN resource in APIs) — Project that has permission to use the shared networking resources from the XPN host project. You can separate service projects so that each service project is operated by a different department in the Cloud Organization. Each department has the ownership of the workloads contained in its project.
- Standalone project — A project that does not share networking resources with any other project.In this context, a project that is not an XPN host project or XPN service project.
- XPN or shared virtual network — A network owned by the XPN host project and shared with one or more service projects in the Cloud Organization.
- IAM roles and policies — Policies that you apply to users, groups, or service accounts that provide permissions for them to manage or use resources in the shared network.
- Organization — The Cloud Organization is the top level in the Cloud Resource Hierarchy and the top-level owner of all the projects and resources created under it. A given XPN host project and its XPN service projects must be under the same Cloud Organization.
- Org admin (
resourcemanager.organizationAdmin) — The administrator for a Cloud Organization.
- XPN admin (
compute.xpnAdmin) — The administrator responsible for configuring XPN in the Cloud Organization by enabling projects as XPN host projects and attaching service projects to host projects. As a best practice, we recommend that the XPN admin also be a project owner on the host project.
Service project admin — A project admin of an XPN service project. Can be project Owners, Editors, Instance admins, or Network admins. See IAM roles for details about these roles.
- Network admin (
compute.networkAdmin) — The administrator with full control of project networking resources.
- Security admin (
compute.securityAdmin) — The administrator with full control of project security resources.
- Network admin (
With XPN, you can make a virtual network shareable across several projects in your Cloud Organization. The shared virtual network must be hosted in a project that you designate as the XPN host project. The following diagram shows an XPN host project sharing its network with two service projects. It is sharing "Subnet_1" with one project and "Subnet_2" with another project.
"Standalone project" has not been designated a service project, so it can share no resources with the XPN host project.
The following are some of the key properties and considerations when using XPN.
XPN within an Organization structure
- You can only use XPN only if the XPN host and service projects all belong to the same Cloud Organization.
- You can create XPN host and service project in a Cloud Organization at any time after the organization is created.
- You can enable or disable an existing project in the Cloud Organization as an XPN host or service project at any time.
- A Cloud Organization can have multiple XPN host projects. The following
diagram illustrates how a Cloud Organization can have two separate
test, each with multiple services. The test environment can be kept isolated from the production environment, and each of them is controlled by their respective administrators.
XPN host project and service project associations
- You can associate a service project with one XPN host project only.
- You cannot designate a project as both a service project and a XPN host project at the same time.
- You can only allocate external IPs from the same project where the resource lives. That is, you can only give an instance created in a service project an external IP from that service project.
- Your existing projects can use XPN networks. All you need to do is to associate them to a XPN host project. However, existing instances in the service network can't be migrated to the XPN network. Those instances need to recreated in the XPN network.
XPN and networks
- All existing and future subnet mode networks and subnetworks of an XPN host
project are shared with its associated service projects. Users with
compute.subnetworks.usepermission on the host project or its subnetworks can use the shared subnetworks.
- Legacy networks in a host project are not shared with service projects. The shared networks in an XPN host project must be subnet mode networks. The networks can be either auto subnet mode or custom subnet mode.
- Each service project can have its own, unshared networks.
- Shared networks charge network quota of the host project the same as non-shared networks.
- A service project can create no more instances or Internal load balancing forwarding rules than its quota allows.
- The host project can have no more instances or Internal load balancing forwarding rules than its quota allows.
- Regardless of quotas, a shared network can have no more than 7000 instances from all projects creating instances in that network. It can have no more than 50 forwarding rules used for Internal load balancing.
- Traffic across projects is billed with the same rules as if it was within a single project.
- In an XPN setup, traffic egress billing is attributed to the project that originated the egress traffic. Egress traffic from a virtual machine instance is attributed to the project where the instance lives.
- Costs associated with a load balancer are charged to the project containing the load balancer.
- Egress traffic to VPNs is attributed to the project that hosts the VPN gateway in GCP. If there is a shared VPN in the XPN host project that is used for several projects in the Cloud Organization, the VPN egress cost for all the projects using the VPN is attributed to the XPN host project.
XPN and DNS
VM instances in a shared XPN host network can communicate with each other
via internal IP addresses even if the instances were created by different
service projects. Instances can also reach each other via fully qualified
internal DNS names in
Resources that can be attached to XPN networks from a service project
This section describes which resources in service projects you can attach to a XPN shared virtual network and its associated subnets. The following cross project associations are allowed:
|XPN service project resource||Permitted in Network or Subnet|
|Instance Template||Network, Subnet|
|Instance Group||Network, Subnet|
|Forwarding rule for Internal load balancing||Network, Subnet|
Service project admins can create instances and instance templates in the shared network.
- When you attempt to create an instance, GCP verifies that you have permission to use the subnet where the instance is created.
- When you attempt to create an instance template, GCP does not check your whether you can use the subnet specified in the instance template. However, when you attempt to create an instance group using the instance template, GCP will check whether you have permissions to all the resources specified in the instance template, including the subnet. This means that while you might have permissions to create an instance template, you might not have permissions to create or use the resources specified in the instance template.
To ensure that you have permission to use a subnet, grant the
compute.networkUser role. See
IAM in XPN for more information about that role.
You can create instance groups (managed and unmanaged) in service projects attached to a shared network. Instances created as part of managed instance group as part of autoscaling use a service account.
You can create Internal load balancers in a shared network from a service project. If an Internal load balancer forwarding rule is in the shared network, any instances in the same shared network and in the same region as the forwarding rule can reach the load balancer service, and through it, the load balanced instances.
You must create external load balancers in the same project as the instances they point to.
The networks in XPN host projects must be in subnet mode to be shared. The following applies when creating instances in subnet mode networks:
- If your network is an auto subnet network, the internal IP address comes from the region's subnet. Therefore, either the network or the subnet can be referenced in the create instance command or create instance template command.
- If your network is a custom subnet network, you must specify which subnet the internal IP address comes from. Therefore, the subnet must be referenced in the create instance command or create instance template command.
External IPs live in the same project as the resource that is using them. This applies to instances and forwarding rules.
Resources not listed in this section are not able to link and use an XPN shared network from service projects.
This section describes common scenarios that can be used as XPN configurations examples.
Two-tier web service
This scenario reflects a a Cloud Organization with two-tier web services, an externally exposed Tier 1 load balancer and a private Internal load balancer as Tier 2. In this example, each load balancer and associated instances is managed by a different team.
The Tier 1 and Tier 2 services can be managed by different teams in the Cloud Organization, each using a different XPN project. Each team has complete control of its service.
- Each team can deploy and operate its services autonomously.
- Each project is billed separately.
- Each project admin can manage their own resources, like virtual machine instances, but has no privileges over the workloads or resources of other teams' projects.
- There can be a single centralized group of network and security admins that are responsible for providing networking connectivity and controlling the security rules for the Cloud Organization.
XPN allows you to map the Tier 1 and Tier 2 services to different projects so that they can be owned autonomously by different teams while sharing a common RFC1918 IP space for the Cloud Organization.
A service project admin in project Service_Tier1 creates an instance template and associated instance groups in a shared XPN host project subnet. A service project admin in project Service_Tier2 creates an Internal load balancer setup in a different subnet of the shared XPN host project network. In both cases, the resources are owned and maintained in the respective service projects, but they operate in the shared network.
For more details on how to create the VM instance templates and the Internal load balancer forwarding rules, see the section on creating resources.
Hybrid cloud scenario
This scenario describes a Cloud Organization with a hybrid environment in which part of the services are hosted in GCP while some of the applications are kept in their on-premises datacenters.
While different services and applications in the cloud are owned by different departments operating autonomously, a common connectivity with on-premises datacenters must be available to the different cloud applications. Additionally, the connectivity and security rules across services and from/to the on-premises datacenter are controlled by Network and Security administrators within the Cloud Organization.
The administration of the services and its connectivity exhibit the following properties in this scenario:
- Each service is owned and operated by a different department and requires separate billing.
- Each service has admin capabilities over its owned resources (e.g, virtual machine instances), but has no privileges over other departments' workloads or resources.
- Services must communicate within an internal RFC1918 space with some centralized services on-premises, for example an LDAP directory, AAA services, or centralized databases.
- There is a single centralized group of Network and Security admins that are responsible for providing networking connectivity and controlling the security rules for the Cloud Organization.
XPN allows you to map
Service3 to different
projects so that they can be owned autonomously by different departments while
sharing a common RFC1918 IP space and a common VPN connectivity with on-premises
resources for all the services in the Cloud Organization .
In this setup, you create the VM instances in the service projects are created with the fully qualified URL or path of the subnet to be used in the XPN host project. These instances can also be created as part of a managed instance group, in which case, the subnetwork is specified as part of the instance templates. As a result, the instances are associated with the specified subnetworks in the XPN host project. The red dashed lines indicate which subnetwork the instances are associated with.
Additionally, the network in the XPN host project that contains the subnetworks has a VPN for private connectivity to on-premises resources. As a consequence, all the instances in the XPN network have connectivity with on-premises datacenter through a common VPN. The blue line indicates the data path connecting Service 1 instances with on-premises resources via the shared VPN.
IAM in XPN
In XPN, the same as with any standalone project, operations are subject to Identity and Access Management (IAM) permission checks.
XPN access is governed by a Cloud IAM policy. IAM policies define a set of bindings between members (e.g., groups) and roles, which define a set of permissions.
GCP IAM allows you to view, set, and test
IAM policies via the
SetIamPolicy calls allow users to retrieve and modify the
IAM ACLs associated with a resource.
IAM roles required for XPN
An XPN admin is responsible for configuring the XPN setup by specifying the
XPN host projects and associating the XPN service projects. XPN host project
admins can also grant
compute.networkUser permissions to service project
compute.networkUser role in the list of
Available IAM roles for role
Shared XPN networks and subnetworks live in a different project from the one
where instances or instance templates are created. An XPN admin
can grant the
compute.NetworkUser role to allow a Service project admin to
"use" a shared XPN project for its instances and instance templates.
The Service project admin must also have relevant permissions in their own
A user must have two different roles in order to create instances and instance templates in an XPN shared network:
- A Service project admin role such as Project Owner, Project Editor, or
compute.instanceAdmin.v1in the service project
compute.networkUserrole at XPN host project or XPN shared subnet level
compute.networkUser role in the list of
Available IAM roles for role