Managing VPC Networks? No Problem! Make sure your teams use the right subnetwork in a Shared-VPC architecture

In GCP, using one or several Shared VPC networks in an organization to streamline communication between projects/teams and on-premises is a best practice.

One interesting fact about how Shared VPC works, is that you give permissions to specific users (or groups) on which subnetworks within the VPC they can use to create their resources (like Compute Engine VM instances for example)

Shared VPC network with Host and Service projects connected to on-premises

Imagine a scenario where an organization designates a project and a subnetwork within a Shared VPC for use by each team within the organization. Let’s also assume that one user is part of multiple teams, and therefore is able to login into multiple projects. Given how Shared VPC subnetwork sharing works, this user will be able to deploy workloads in any of the subnetworks that have been shared with her/him; regardless of the specific project she/he is logged into. So it could happen that when creating resources in one of the projects the user may accidentally use the incorrect subnetwork: this can lead to confusion and potentially to connection problems due to mismatched deployment of firewalls rules.

While other approaches exist to cope with situations like this, GCP customers can now leverage a new fully platform-based solution based on a new Organizational policy constraint called “Restrict Shared VPC Subnetworks”(see the list of available constraints for other goodies you might not know about). Despite the name, many of the constraints can be applied at an organizational level, but also on specific folders or at project level. This is a big deal, since it matches the holistic nature of your IAM hierarchy, and policies can be inherited.

Typical organizational resource hierarchy

Now how does applying this constraint work in practice and help in the situation described above ?

Assume the DB admin team called “Team Orange” has been assigned a service project named (surprise !) Orange, while the Active Directory admin team called “Team Blue” has been assigned a service project named (another surprise !) Blue. The folder structure used for those projects is simple, and is shown here for reference.

Organizational resource hierarchy used

A user named orange is a superhero who is not only part of his native team (Team Orange), but also of the other team (Team Blue).

Finally user orange has been user permission over two subnetworks of the host project VPC:

• sub-192–168–2–48-m28-euw3
• sub-192–168–2–0-m28-euw4

When the organizational policy constraint “Restrict Shared VPC Subnetworks” is not applied, user orange can login in any of the two projects and see both the subnetwork that has been shared with him/her: for example here is the view when logged into the Orange project (the view from the Blue project would be the same)

These subnetworks could have nicer names, indeed

However, if the proper policy constraint is applied to project Orange, this user will be able to use only one of the two subnetworks to deploy resources like compute instances: in the example he/she can only use sub-192–168–2–0-m28-euw4

You are not using the right one!

Let’s take a look at the organizational policy constraint used: as you can see the policy is enforced to project “Orange” by inheritance (it is applied at folder Orange-SP level) and allows precisely only one of the two subnetworks.

This is not the subnet you were using before!

To complete the setup, the symmetric policy constraint is applied to the Blue-SP folder and, by inheritance, to the Blue project: this time only the subnetwork sub-192–168–2–48-m28-euw3 is allowed

Makes sense, right?

So what happens when user orange logs into project Blue and tries to deploy in the subnet in which the deployment failed before?

To sum up, in a shared VPC setup the new organizational policy constraint “Restrict Shared VPC Subnetworks” allows to specify which subnets shared from the host project can be used in each service project. As shown in the previous example it can be used to avoid users from mistakenly deploying a compute instance in the wrong subnetwork or in the wrong project, depending on how you see it.

If you dedicate specific projects and subnetworks by team, application or workload, it is definitely part of the best practices to activate this constraint now per project or folder for the right subnetworks.

Thank you Emanuele for contributing the pictures and the user story to this post.