Configuring discrimiNAT for a Shared VPC
How to configure the discrimiNAT Firewall for working in a GCP Shared VPC
Table of Contents
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, 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, a level up from the host project, that allows getting information about firewall rules, associated projects and compute instances within. Details in the Role section below.
- An organisation-level IAM Permission 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 the discrimiNAT instances must be explicity 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 to the discrimiNAT would have to be created.
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:
compute.firewalls.list compute.instances.list compute.projects.get logging.logEntries.create
This Role must be created at the organisation-level, a level up from the host project.
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
logging-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 the discrimiNAT would have to be created. The discrimiNAT instances are deployed with a
discriminat-itself network tag for ease in defining any 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.
Can the service account be changed on-the-fly?
Our usual deployment patterns encapsulate the instances in a Managed Instance Group (MIG). Any change is applied to the MIG template, which then does need to restart the instances in order to change the service account. If deployed behind an Internal Load Balancer (ILB), there will be near-zero downtime while the instances roll-over. If routed to directly, there will be a minute or two’s interruption.
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.