Shared VPC Overview

Shared VPC allows an organization to connect resources from multiple projects to a common VPC network, so that they can communicate with each other securely and efficiently using internal IPs from that network. When you use Shared VPC, you designate a project as a host project and attach one or more other service projects to it. The VPC networks in the host project are called Shared VPC networks. Eligible resources from service projects can use subnets in the Shared VPC network.

Shared VPC lets organization administrators delegate administrative responsibilities, such as creating and managing instances, to Service Project Admins while maintaining centralized control over network resources like subnets, routes, and firewalls. This model allows organizations to do the following:

  • Implement a security best practice of least privilege for network administration, auditing, and access control. Shared VPC Admins can delegate network administration tasks to Network and Security Admins in the Shared VPC network without allowing Service Project Admins to make network-impacting changes. Service Project Admins are only given the ability to create and manage instances that make use of the Shared VPC network. Refer to the administrators and IAM section for more details.
  • Apply and enforce consistent access control policies at the network level for multiple service projects in the organization while delegating administrative responsibilities. For example, Service Project Admins can be Compute Instance Admins in their project, creating and deleting instances that use approved subnets in the Shared VPC host project.
  • Use service projects to separate budgeting or internal cost centers. Refer to the billing section for more details.

Concepts

Organizations, folders, and projects

Shared VPC connects projects within the same organization. Participating host and service projects cannot belong to different organizations. Linked projects can be in the same or different folders, but if they are in different folders the admin must have Shared VPC Admin rights to both folders. Refer to the GCP resource hierarchy for more information about organizations, folders, and projects.

A project that participates in Shared VPC is either a host project or a service project:

  • A host project contains one or more Shared VPC networks. A Shared VPC Admin must first enable a project as a host project. After that, a Shared VPC Admin can attach one or more service projects to it.

  • A service project is any project that has been attached to a host project by a Shared VPC Admin. This attachment allows it to participate in Shared VPC. It's a common practice to have multiple service projects operated and administered by different departments or teams in your organization.

  • A project cannot be both a host and a service project simultaneously. Thus, a service project cannot be a host project to further service projects.

  • You can create and use multiple host projects; however, each service project can only be attached to a single host project. See the Multiple host projects example for an illustration.

For clarity, a project that does not participate in Shared VPC is called a standalone project. This emphasizes that it is neither a host project nor a service project.

Networks

A Shared VPC network is a VPC network defined in a host project and made available as a centrally shared network for eligible resources in service projects. Shared VPC networks can be either auto or custom mode, but legacy networks are not supported.

When a host project is enabled, all of its existing VPC networks become Shared VPC networks, and any new network created in it will automatically be a Shared VPC network as well. Thus, a single host project can have more than one Shared VPC network.

Host and service projects are connected by attachments at the project level. Subnets of the Shared VPC networks in the host project are accessible by Service Project Admins as described in the next section, administrators and IAM.

Administrators and IAM

Shared VPC makes use of Identity and Access Management (IAM) roles for delegated administration. The following roles can be granted to IAM members, such as users, Google groups, Google domains, or GCP service accounts. If you need to contact any of these admins, you can look them up in your organization's or project's IAM policy. If you don't have the required permissions, you must contact a network or project administrator in your organization.

Required administrative roles

Administrator Purpose
Organization Admin
  • IAM member in the organization
Organization Admins have the resourcemanager.organizationAdmin role for your organization. They nominate Shared VPC Admins by granting them appropriate project creation and deletion roles, and the Shared VPC Admin role for the organization. These admins can define organization-level policies, but specific folder and project actions require additional folder and project roles.
Shared VPC Admin
  • IAM member in the organization, or
  • IAM member in a folder (beta)
Shared VPC Admins have the Shared VPC Admin (compute.xpnAdmin) role for the organization or one or more folders. They perform various tasks necessary to set up Shared VPC, such as enabling host projects, attaching service projects to host projects, and delegating access to some or all of the subnets in Shared VPC networks to Service Project Admins. A Shared VPC Admin for a given host project is typically its project owner as well.
A user assigned the Shared VPC Admin role for the organization has that role for all folders in the organization. A user assigned the role for a folder has that role for the given folder and any folders nested underneath it. A Shared VPC Admin can link projects in two different folders only if the admin has the role for both folders.
Service Project Admin
  • IAM member in a service project, or
  • IAM member in the organization
A Shared VPC Admin defines a Service Project Admin by granting an IAM member the Network User (compute.networkUser) role to either the whole host project or select subnets of its Shared VPC networks. Service Project Admins also maintain ownership and control over resources defined in the service projects, so they should have the Instance Admin (compute.instanceAdmin) role to the corresponding service projects. They may have additional IAM roles to the service projects, such as project owner.

Service Project Admins

When defining each Service Project Admin, a Shared VPC Admin can grant permission to use the whole host project or just some subnets:

  • Project-level permissions: A Service Project Admin can be defined to have permission to use all subnets in the host project if the Shared VPC Admin grants the role of compute.networkUser for the whole host project to the Service Project Admin. The result is that the Service Project Admin has permission to use all subnets in all VPC networks of the host project, including subnets and VPC networks added to the host project in the future.

  • Subnet-level permissions: Alternatively, a Service Project Admin can be granted a more restrictive set of permissions to use only some subnets if the Shared VPC Admin grants the role of compute.networkUser for those selected subnets to the Service Project Admin. A Service Project Admin who only has subnet-level permissions is restricted to using only those subnets. After new Shared VPC networks or new subnets are added to the host project, a Shared VPC Admin should review the permission bindings for the compute.networkUser role to ensure that the subnet-level permissions for all Service Project Admins match the intended configuration.

Network and Security Admins

Shared VPC Admins have full control over the resources in the host project, including administration of the Shared VPC network. They can optionally delegate certain network administrative tasks to other IAM members:

Administrator Purpose
Network Admin
  • IAM member in the host project, or
  • IAM member in the organization
Shared VPC Admin define a Network Admin by granting an IAM member the Network Admin (compute.networkAdmin) role to the host project. Network Admins have full control over all network resources except for firewall rules and SSL certificates.
Security Admin
  • IAM member in the host project, or
  • IAM member in the organization
A Shared VPC Admin can define a Security Admin by granting an IAM member the Security Admin (compute.securityAdmin) role to the host project. Security Admins manage firewall rules and SSL certificates.

Specifications

Quotas and limits

Shared VPC host projects are subject to standard per-project VPC quotas. Shared VPC networks are subject to the per-network limits and per-instance limits for VPC networks. Additionally, the relationship between host and service projects are governed by limits specific to Shared VPC.

Billing

Billing for resources that participate in a Shared VPC network is attributed to the service project where the resource is located, even though the resource uses the Shared VPC network in the host project.

  • The rates and rules used to calculate billing amounts for resources in service projects using a Shared VPC network is the same as if the resources were located in the host project itself.
  • Billing for egress traffic generated by a resource is attributed to the project where the resource is defined:
    • Egress traffic from an instance is attributed to the project containing the instance. For example, if an instance is created in a service project but uses a Shared VPC network, any billing for egress traffic that it generates is attributed to its service project. In this way, you can use Shared VPC to organize resources into cost centers for your organization.
    • Costs associated with a load balancer are charged to the project containing the load balancer components. For more details about load balancing and Shared VPC, refer to the load balancing section.
    • Egress traffic to VPNs is attributed to the project containing the VPN Gateway resource. For example, if a VPN Gateway is created in the Shared VPC network, it is contained in the host project. Egress traffic through the VPN Gateway — regardless of which service project initiates the egress — is attributed to the host project.

Resources

Eligible resources

The following service project resources can participate in Shared VPC subject to certain practical limitations:

Practical limitations for eligible resources

The following limitations apply to resources that are eligible for participation in a Shared VPC scenario:

  • Use of a Shared VPC network is not mandatory. For example, instance admins can create instances in the service project that use a VPC network in that project. Networks defined in service projects are not shared.

  • Some resources must be re-created in order to use a Shared VPC network. When a Shared VPC Admin attaches an existing project to a host project, that project becomes a service project, but its existing resources do not automatically use shared network resources. To use a Shared VPC network, a Service Project Admin has to create an eligible resource and configure it to use a subnet of a Shared VPC network. For example, an existing instance in a service project cannot be reconfigured to use a Shared VPC network, but a new instance can be created to use available subnets in a Shared VPC network. This limitation applies to private zones.

Ineligible resources

In a service project, App Engine Flexible resources cannot participate in Shared VPC.

IP addresses

Instances in service projects attached to a host project using the same Shared VPC network can communicate with one another using either ephemeral or reserved static internal IP addresses, subject to applicable firewall rules.

An ephemeral internal IP address can be automatically assigned to an instance in a service project. For example, when Service Project Admins create instances, they select a zone, the Shared VPC network, and an available subnet. The IP address comes from the range of available IP addresses in the selected shared subnet.

Alternatively, a Service Project Admin can choose to reserve a static internal IP address. The IP address object itself must be created in the same service project as the instance that will use it, even though the value of the IP address will come from the range of available IPs in a selected shared subnet of the Shared VPC network. Refer to reserving a static internal IP on the Provisioning Shared VPC page for more information.

External IP addresses defined in the host project are only usable by resources in that project. They are not available for use in service projects. Service projects can maintain their own set of external IP addresses. For example, an instance in a service project must use an external IP address defined in that same service project. This is the case even if the instance uses an internal IP address from a Shared VPC network in the host project.

Internal DNS

VMs in the same service project can reach each other using the internal DNS names that GCP creates automatically. These DNS names use the project ID of the service project where the VMs are created, even though the names point to internal IP addresses in the host project. For a complete explanation, refer to Internal DNS names and Shared VPC in the Internal DNS documentation.

Cloud DNS private zones

You can use Cloud DNS private zones in a Shared VPC network. You must create your private zone in the host project and authorize access to the zone for the Shared VPC network. Additionally, you must activate private DNS zones within each service project. For a complete explanation, refer to Private zones and Shared VPC in the Cloud DNS overview.

Load balancing

Shared VPC can be used in conjunction with load balancing. All load balancing components must exist in the same project, either all in a host project or all in a service project. Creating some load balancer components in a host project and others in an attached service project is not supported. However, the internal forwarding rule for an internal load balancer created in a service project can reference a shared subnet in the host project to which the service project is attached. Refer to creating an internal load balancer on the Provisioning Shared VPC page for more information.

The following table summaries components for HTTP(S), SSL Proxy, and TCP Proxy Load Balancing. In most cases, you create the backend instances in a service project. In this case, all load balancer components are created in that project. It's also possible to create the backend instances in the host project; in that case, all load balancer components would need to be in the host project.

Load balancer IP Address Forwarding Rule Other Frontend Components Backend Components
HTTP(S) Load Balancing An external IP address must be defined in the same project as the instances being load balanced (the service project). The external forwarding rule must be defined in the same project as the backend instances(the service project). The target HTTP proxy or target HTTPS proxy and associated URL map must be defined in the same project as the backend instances. A global backend service must be defined in the same project as the backend instances. These instances must be in instance groups attached to the backend service as backends. Health checks associated with backend services must be defined in the same project as the backend service as well.
SSL Proxy Load Balancing The target SSL proxy must be defined in the same project as the backend instances.
TCP Proxy Load Balancing The target TCP proxy must be defined in the same project as the backend instances.

The following table summaries components for the two types of regional load balancers. It highlights how an internal forwarding rule for an internal load balancer can reference a shared subnet in a Shared VPC network to provide internal load balancing within that network.

Load balancer IP Address Forwarding Rule Backend Components
Network Load Balancing A regional external IP address must be defined in the same project as the instances being load balanced. A regional external forwarding rule must be defined in the same project as the instances in the target pool (the service project). The target pool must be defined in the same project and same region where the instances in the target pool exist. Health checks associated with the target pool must be defined in the same project as well.
Internal Load Balancing The internal IP address can come from either the host or the service project:
  • If the load balancer should be available to the Shared VPC network, the internal IP address must come from the primary IP address range of a shared subnet.
  • If the load balancer should be local to one service project, the internal IP address can come from a subnet in a network in the service project.
An internal forwarding rule must be defined in the same project as the instances being load balanced; however, the subnet that it references determines if the load balancer works in a Shared VPC scenario:
  • If the load balancer should be available to the Shared VPC network, the forwarding rule must reference a shared subnet. Refer to creating an internal load balancer on the Provisioning Shared VPC page for specific directions.
  • If the load balancer should be local to one service project, the forwarding rule can reference a subnet in a network in that service project.
A regional backend service must be defined in the same project as the instances being load balanced. Instances being load balanced must be in instance groups attached to the backend service as backends. Health checks associated with backend services must be defined in the same project as the backend service as well.

Examples and use cases

Basic concepts

The following example illustrates a simple Shared VPC scenario:

Basic concepts (click to enlarge)
Basic concepts (click to enlarge)
  • A Shared VPC Admin for the organization has created a host project and attached two service projects to it:

    • Service Project Admins in Service Project A can be configured to access all or some of the subnets in the Shared VPC network. A Service Project Admin with at least subnet-level permissions to the 10.0.1.0/24 Subnet has created Instance A in a zone of the us-west1 region. This instance receives its internal IP address, 10.0.1.3, from the 10.0.1.0/24 CIDR block.

    • Service Project Admins in Service Project B can be configured to access all or some of the subnets in the Shared VPC network. A Service Project Admin with at least subnet-level permissions to the 10.15.2.0/24 Subnet has created Instance B in a zone of the us-east1 region. This instance receives its internal IP address, 10.15.2.4, from the 10.15.2.0/24 CIDR block.

  • The Standalone Project does not participate in the Shared VPC at all; it is neither a host nor a service project. Standalone instances are created by IAM members who have at least the compute.InstanceAdmin role for the project.

Multiple host projects

The following example demonstrates how Shared VPC can be used to build separate testing and production environments. For this case, an organization has decided to use two separate host projects, a Test Environment and a Production Environment.

Multiple host projects (click to enlarge)
Multiple host projects (click to enlarge)
  • A Shared VPC Admin for the organization has created two host projects and attached two service projects to them as follows:

    • The Apps Testing and Mobile Testing service projects are attached to the Test Environment host project. Service Project Admins in each may be configured to access all or some of the subnets in the Testing Network.

    • The Apps Production and Mobile Production service projects are attached to the Production Environment host project. Service Project Admins in each may be configured to access all or some of the subnets in the Production Network.

  • Both host projects have one Shared VPC network with subnets configured to use the same CIDR ranges. In both the Testing Network and Production Network, the two subnets are:

    • 10.0.1.0/24 Subnet in the us-west1 region

    • 10.15.2.0/24 Subnet in the us-east1 region

  • Consider Instance AT in the Apps Testing service project and Instance AP in the Apps Production service project:

    • Service Project Admins can create instances like them provided they have at least subnet-level permissions to the 10.0.1.0/24 Subnet.

    • Notice that both instances use the IP address 10.0.1.3. This is acceptable because each instance exists in a service project attached to a unique host project containing its own Shared VPC network. Both the testing and production networks have been purposefully configured in the same way.

    • Instances using the 10.0.1.0/24 Subnet must be located in a zone in the same region as the subnet, even though the subnet and instances are defined in separate projects. Because the 10.0.1.0/24 Subnet is located in the us-west1 region, Service Project Admins who create instances using that subnet must choose a zone in the same region, such as us-west1-a.

Hybrid cloud scenario

The following example demonstrates how Shared VPC can be used in a hybrid environment.

Hybrid cloud (click to enlarge)
Hybrid cloud (click to enlarge)

For this example, an organization has a created a single host project with a single Shared VPC network. The Shared VPC network is connected via Cloud VPN to an on-premises network. Some services and applications are hosted in GCP while others are kept on-premises:

  • A Shared VPC Admin enabled the host project and connected three service projects to it: Service Project A, Service Project B, and Service Project C.

    • Separate teams can manage each of the service projects. IAM permissions have been configured such that a Service Project Admin for one project has no permissions to the other service projects.

    • The Shared VPC Admin has granted subnet-level or project-level permissions to the necessary Service Project Admins so they can create instances that use the Shared VPC network:

      • A Service Project Admin for Service Project A who has subnet-level permissions to the 10.0.1.0/24 Subnet can create Instance A in it. The Service Project Admin has to choose a zone in the us-west1 region for the instance, because that is the region that contains the 10.0.1.0/24 Subnet. Instance A receives its IP address, 10.0.1.3, from the range of free IP addresses in 10.0.1.0/24 Subnet.

      • A Service Project Admin for Service Project B who has subnet-level permissions to the 10.15.2.0/24 Subnet can create Instance B in it. The Service Project Admin has to choose a zone in the us-east1 region for the instance, because that is the region that contains the 10.15.2.0/24 Subnet. Instance B receives its IP address, 10.15.2.4, from the range of free IP addresses in 10.15.2.0/24 Subnet.

      • A Service Project Admin for Service Project C who has project-level permissions to the whole host project can create instances in any of the subnets in any of the VPC networks in the host project. For example, the Service Project Admin can create Instance C in the 10.7.1.0/24 Subnet, choosing a zone in the us-east1 region to match the region for the subnet. Instance C receives its IP address, 10.7.1.50, from the range of free IP addresses in 10.7.1.0/24 Subnet.

    • Each service project is billed separately.

    • The Service Project Admins in each project are responsible for creating and managing resources.

  • A Shared VPC Admin has delegated network administration tasks to other IAM members who are Network and Security Admins for the Shared VPC network.

    • A Network Admin has created a Cloud VPN gateway and configured a VPN tunnel through the Internet to an on-premises gateway. The Cloud VPN exchanges and receives routes with its on-premises counterpart because a corresponding Cloud Router in the same us-east1 region has been configured.

    • If the dynamic routing mode of the VPC is global, the Cloud Router applies the learned routes to the on-premises network in all subnets in the VPC network, and it shares routes to all of the VPC subnets with its on-premises counterpart.

    • Security Admins create and manage firewall rules in the Shared VPC network to control traffic among instances in GCP and the on-premises network.

    • Subject to applicable firewall rules, instances in the service projects can be configured to communicate with internal services, such as database or directory servers located on-premises.

Two-tier web service

The following example demonstrates how Shared VPC can be employed to delegate administrative responsibilities and maintain the principle of least privilege. For this case, an organization has a web service that is separated into two tiers, and different teams manage each tier. Tier 1 represents the externally-facing component, behind a Global HTTP Load Balancer. Tier 2 represents an internal service upon which Tier 1 relies, and it is balanced using an Internal Load Balancer.

Two-tier web service (click to enlarge)
Two-tier web service (click to enlarge)

Shared VPC allows you to map each tier of the web service to different projects so that they can be managed by different teams while sharing a common VPC network:

  • Resources, such as instances and load balancer components, for each tier are placed in individual service projects managed by different teams.

  • Each tier service project has been attached to the host project by a Shared VPC Admin. The Shared VPC Admin also enabled the host project.

    • Separate teams can manage each tier of the web service by virtue of being a Service Project Admin in the appropriate service project.

    • Each service project is billed separately.

    • The Service Project Admins in each project are responsible for creating and managing resources.

  • Network access control is delineated as follows:

    • IAM members who only work on Tier 1 are Service Project Admins for the Tier 1 Service Project and are granted subnet-level permissions for just the 10.0.1.0/24 Subnet. In this example, one such Service Project Admin has created three Tier 1 Instances in that subnet.

    • IAM members who only work on Tier 2 are Service Project Admins for the Tier 2 Service Project and are granted subnet-level permissions for just the 10.0.2.0/24 Subnet. In this example, another Service Project Admin has created three Tier 2 Instances in that subnet along with an internal load balancer whose forwarding rule uses an IP address from the range available in that subnet.

    • IAM members who oversee the whole web service are Service Project Admins in both service projects, and they have project-level permissions to the host project so they can use any subnet defined in it.

    • Optionally, a Shared VPC Admin can delegate network administration tasks to Network and Security Admins.

What's next

هل كانت هذه الصفحة مفيدة؟ يرجى تقييم أدائنا:

إرسال تعليقات حول...