Shared VPC allows an organization to connect resources from multiple projects to a common Virtual Private Cloud (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 VPCs in Google Cloud Platform have emerged as a robust design pattern for scaling business units and their services in an enterprise setting.
The DiscrimiNAT firewall, from v2.3 onwards, supports the Shared VPC topology.
- An IAM service account, in the host project, must be created for use by DiscrimiNAT instances.
- An organisation-level IAM Role must exist that allows getting information about firewall rules, associated service projects and compute instances within. Details in the Role section below.
- A folder-level (or organisation-level) IAM binding granting that IAM Role to the Principal of the service account must exist.
- The DiscrimiNAT firewall must be deployed in the host project.
- The service account for DiscrimiNAT instances must be explicitly set to the Principal of that service account.
- The egress-filtered workload may be deployed in the host project and/or any attached service projects.
- Firewall Rules to allow connections from the egress-filtered workloads' subnets to DiscrimiNAT instances would have to be created. If using Terraform, the variable
client_cidrsaccepts a list for this.
This Role must be created at the organisation-level.
The following permissions must be added to the Role meant to be granted to the service account for DiscrimiNAT instances, in order for it to be able to pick up the firewall rules, the associated projects and the compute instances within:
Also see the Service Account page for other permissions of interest.
If using Terraform, a new variable from v2.3 onwards has been introduced to let the user override the service account used by DiscrimiNAT instances. This is the
custom_service_account_email variable and if left unset, defaults to the default compute engine service account with limited scopes of
monitoring-write. If set to the Principal of any service account, assigns that service account to the instances and changes the scope to
Firewall Rules to allow connections from the egress-filtered workloads to DiscrimiNAT instances would have to be created. If using Terraform, the variable
client_cidrs accepts a list for this. DiscrimiNAT instances are deployed with a
discriminat-itself network tag for ease in defining any other network rules.
Does DiscrimiNAT work without a custom service account?
Yes. In a non-Shared VPC setting, it is able to work for private IP workloads in the same project as itself. In a Shared VPC setting, it will behave in a similar fashion and work for private IP workloads in the same project as itself. However, traffic arriving from other Projects will simply be rejected.
Is there a setting in the DiscrimiNAT to be toggled for Shared VPC support?
No. The DiscrimiNAT figures out the best possible setting looking at the service account, the permissions that come with it, and whether it is indeed in a host project with a Shared VPC.
Where are the Firewall Rules defined in a Shared VPC setting?
The Firewall Rules are defined at the VPC-level in a Shared VPC. With that constraint, they can only be defined in the host project. The Firewall Rules can be defined upfront to apply to only certain targets with Network Tags. These Network Tags can then be applied and used in the service projects on any compute workloads with only private IPs, and the DiscrimiNAT will figure out the FQDN egress rules to apply to each client as usual.