Juggling multiple environments in GCP? Feeling the weight of countless VMs for dev, test, and production? You’re not alone! While spinning up separate VMs might work for tiny projects, it quickly becomes a scalability nightmare. This blog unveils a powerful solution: Google Shared Virtual Private Cloud Network (VPC). Imagine running multiple isolated environments within a single, centrally controlled VPC, streamlining your resources while having full control of your network infrastructure! Sit tight and discover the magic of Google Shared VPC.
What is a Google Shared VPC?
Imagine a single network housing your dev, test, and prod environments, each residing in separate projects. That’s the magic of Shared VPC. Unlike other cloud service vendors, GCP offers you a network infrastructure that allows you to attach resources from multiple projects to a single VPC. Traditionally, GCP provides each project its own VPC on provision. This has its benefits, a subject we can discuss in a later article.
The Pros of a Shared VPC
- Simplified management: With a shared VPC, you can manage all your organization resources, across environments or teams since they are all operating on a single network. You can enforce consistent network policies and security configurations across environments.
- Seamless collaboration: Collaboration is easy since all your environments are operating in a single network. Several projects can share resources like Cloud SQL instances and Cloud Storage buckets with zero to no costs in data transfer.
The Architecture of Google Shared VPC
I have given a background on what a shared VPC in GCP is, but how does a shared VPC work under the hood? A shared VPC consists of three main components, a host project, service projects, and a shared VPC network. Let’s delve into the architectural intricacies of Shared VPC.
The Core Components
- Host project: This is the central authority. It houses the Shared VPC and is responsible for all the network resource management. A host project can have one or more Shared VPCs. To create a host project, a Shared VPC Admin has to enable a project as the host. After this, the admin can now attach one or more service projects to the host.
- Service projects: These are the projects attached to the host project by a Shared VPC. This action can only be done by a Shared VPC Admin. Several service projects can be attached to a single host project.
- A Shared VPC Network: This is a VPC network specified in a host project and is made accessible to qualified resources in service projects as a centrally shared network. In a shared VPC, all the host projects’ subnets can be shared and thus accessible to all the service projects. Alternatively, you can specify subnets to be shared. This means that service projects will only have access to the subnets you shared in the host project.
So how will a Shared VPC Work?
Let’s say you are the architect of your organization. You want to build your organization infrastructure in GCP, but you want your development, testing, and production environments to be isolated. You also want your analytics, engineering, and content teams to have their own environments. However, you also want to be in charge of the networking infrastructure so that you can use singular firewall rules that apply to all of these environments and teams. This is where the magic of a Shared VPC sets in.
Working on the assumption that you are the organization admin in GCP or you at least have the Shared VPC Admin role assigned to you, you should be able to set up a Shared VPC Network without any permissions constraints. To do this, you need to first enable a host project.
You can do this with the following piece of code;
gcloud compute shared-vpc enable HOST_PROJECT_ID
gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_ID \
--host-project HOST_PROJECT_ID
After this, you need to attach your service projects to the host project.
You can then repeat the above step for all the service projects you need to attach to the host project. With your host project enabled and service projects attached, you need to assign the Service Project Admin roles to your respective service projects team leads. You can assign Service Project Admin roles for all subnets, or assign Service Project Admin roles for specific subnets.
Service Project Admin role for all subnets;
gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
--member "user:SERVICE_PROJECT_ADMIN" \
--role "roles/compute.networkUser"
Service project admin role for some subnets;
gcloud compute networks subnets get-iam-policy SUBNET_NAME \
--region SUBNET_REGION \
--project HOST_PROJECT_ID \
--format json
Note: A project cannot concurrently be a service project and a host project. Consequently, a service project cannot serve as a host project for another service project. Similarly, multiple host projects can be created and used, but each service project can only be attached to a single host project
What does the Service Project Admin role do?
Principals with this role have access to a shared host project VPC network. These are the individuals or service accounts you are giving access to the various service projects you attached to your host VPC. Access can be granted to all the subnets in the VPC, or you can make access more granular by restricting access to some subnets in your network. The beauty about this is that though the principals of each service project are operating on the same network, their access to resources is limited to their projects alone.
What’s the catch?
- Security: If you require total isolation of your environments, then a Shared VPC might not be for you. One of its weaknesses is that some changes made in the host project can easily propagate across all your service projects. This is why access to the host project should only be granted on a need-to basis.
What are the alternatives?
When security is your biggest concern, then VPC peering is what you need. With VPC peering, each project operates on its own VPC but with a secure bridge connecting one VPC to another. One of the major problems with VPC peering is the management overhead when dealing with a large organization.
Picture a scenario where your organization has ten distinct environments, each with its dedicated VPC. As an architect, the responsibility falls on you to oversee the network infrastructure for all these diverse environments. Now, for any communication to occur between these environments, you must establish and manage VPC peering connections between each of these networks. This is VPC peering in a nutshell. It is a solution that, while effective, introduces substantial management overhead. It is a less efficient choice for enterprises with significant networking requirements since managing the complexities of multiple separate VPCs and keeping up the related peering connections adds to the complexity.
Conclusion
Juggling several environments in GCP can be daunting. However, this blog has delved into one of the best ways you can achieve this with a Google Shared VPC. This blog has also compared Shared VPC to VPC peering for heightened security needs. Ready to unlock the power of Shared VPC? Start small with a proof-of-concept, consult experts for tailored guidance, and stay informed about best practices.
Remember, the journey to a smoother multi-environment management begins with a single step. Now, go forth and conquer
