Understanding Shared VPCs in Google Cloud Platform
… and a quick guide to set it up
Google Cloud Platform (GCP) provides several tools and features that enable organizations to deploy and manage their infrastructure in the cloud. Two main options to use VPCs between different VPC projects are: Network Peering and Shared VPC. In this article we will focus on what Shared VPC is and how it can be used to improve VPC management in Google Cloud.
A Shared VPC allows multiple projects to share a common VPC network. In this setup, one project is designated as the host project, whiother projects are connected to the host project’s VPC network as service projects. This enables resources in the service projects to communicate securely with resources in the host project’s VPC network, without the need for complex network configuration.
Benefits
Shared VPCs offer several benefits to organizations.
- Least Privilege: Shared VPC Admins can delegate network administration responsibilities to Network and Security Admins within the Shared VPC network. This ensures that Service Project Admins are restricted from making network-impacting changes. Instead, they are only granted permissions to create and manage instances that utilize the Shared VPC network, promoting the principle of least privilege.
- Consistent Access Control: Organizations can enforce consistent access control policies at the network level across multiple service projects. Service Project Admins can be designated as Compute Instance Admins within their projects, granting them the ability to create and delete instances using approved subnets within the Shared VPC host project. This approach ensures uniform security measures while delegating administrative tasks.
- Budgeting and Cost Separation: Service projects can be utilized to separate budgeting or internal cost centers. This allows organizations to effectively manage and allocate costs associated with different projects or departments, enhancing financial control and accountability.
Shared VPCs are particularly useful for organizations that have multiple departments or teams working on separate projects. By using a Shared VPC, each department or team can have its own project while still being able to share a common VPC network. This allows them to work independently while still having access to shared resources.
Requirements
APIs
The first requeriment for creating Shared VPC in the project is having Compute Engine API and billing enabled.
Required Roles
For the host project in a Shared VPC setup, the necessary roles are the Shared VPC Admin role and the Compute Network Admin role. The Shared VPC Admin role allows managing Shared VPC resources, while the Compute Network Admin role grants permissions to configure networking settings.
For the service projects connected to the Shared VPC, the necessary role is the Compute Network User role. This role enables the service projects to use the shared network resources provided by the host project without having administrative privileges.
Configure Shared VPC in the host project
In this example, we will create a new VPC, shared-vpc1 that will share its subnets to other projects. This VPC has 2 subnets, subnet1 and subnet2. Default VPC has been deleted as recommended by Googles best practices.
Going to Shared VPC tab, we can start setting up Shared VPC in this project:
There are several steps that needs to be configured in this mini-wizard, first of all is enabling Shared VPC feature in the host project.
Next is to decide if we will share all subnets of the host project or just specific ones. In this example, in this example, we will share all subnets of the project.
Finally we need to decide which level of access will users in a service project have when using subnets from a host project.
In the console, service project is also referred as an attached project.
If you want to use Shared VPC to create GKE cluster in a service project, make sure to check the option “Kubernetes Engine Access”. This allows the access to secondary IP ranges as well, which is required when selecting ip ranges for pods and services in a GKE. Also, make sure to give necessary permissions that were explained earlier to a service account that is used for creating a GKE cluster (by default it’s a “Compute Engine default service account”)
After this, Shared VPC is enabled in a host project, but we still need to share VPC with other projects. In order to do that, we can switch back to Shared VPC page. New tab appears named Attached projects tab. We can click there and attach our service project.
After selecting a service project and which subnets it will use, click save at the end to attach the service project to a Shared VPC of the host project.
Once the Shared VPC is set up, service projects can create and manage their own resources using network from the Shared VPC. The host project can set policies to manage access to these resources and can monitor network traffic to ensure compliance with security policies.
To verify this, we can go to the service project and try to create a new VM instance. Initiating the VM instance creation, we can go to the advanced settings/networking. A new tab appears in the section of selecting the network “Networks shared with me”.
Make sure to mach the region where VM is created to a subnet that is configured in a host project, if you are selecting any other region, the VM creation cant proceed as it will not find a subnet.
Shared VPCs also offers several advanced features that can further improve network management and security. For example, organizations can use Shared VPCs with Private Service Access to connect to Google services, such as Cloud SQL, without exposing their resources to the public internet. This can help to reduce the risk of security breaches and ensure compliance with regulatory requirements.
In addition, Shared VPCs can be used with Traffic Director, GCP’s advanced traffic management service, to optimize network performance and reliability. Traffic Director allows organizations to control traffic routing and load balancing across multiple regions and VPC networks, ensuring that resources are available and responsive to users.
Overall, Shared VPCs are a powerful tool for managing cloud infrastructure in Google Cloud Platform. They can help organizations to improve network security, reduce costs, and enable teams to work independently while still having access to shared resources. With advanced features such as Private Service Access and Traffic Director, organizations can further optimize their network management and achieve better performance and reliability.
Which GCP native products can use Shared VPC
In Google Cloud Platform (GCP), several resources can utilize a Shared VPC (Virtual Private Cloud). These resources include:
- Compute Engine instances: VMs running on Compute Engine can be part of a Shared VPC, allowing them to leverage the shared network resources provided by the host project.
- GKE clusters: GKE clusters can be configured to use a Shared VPC, enabling containerized workloads to communicate over the shared network.
- Cloud SQL: Managed databases, such as Cloud SQL, can be connected to a Shared VPC, allowing them to be accessed by instances in the same network.
- Memorystore: In-memory data stores like Memorystore for Redis can also utilize a Shared VPC for network connectivity.
- Cloud Functions, Cloud Run, and App Engine: Serverless computing services like Cloud Functions, Cloud Run, and App Engine can be integrated with a Shared VPC to enable network communication within the shared environment.
These are just a few examples, and the list of resources that can use Shared VPC is not limited to these. Different GCP services may have varying degrees of compatibility with Shared VPC, so it’s important to consult the official documentation or specific service guides for the most accurate and comprehensive information.
