The discrimiNAT requires different permissions to work effectively across differing setups.
The most basic of the setups is a single project with only VM instances to protect within the same project. The permissions for this are included with our Deployment Manager template and Terraform modules as allowed scopes on the discrimiNAT instances.
For the rest, and if you'd rather manage the service account with discrete permissions, the following should come in handy.
For all features and topologies enabled,
- Create an IAM service account, in a host project, for use by discrimiNAT instances.
- Create an organisation-level IAM Role with the following permissions.
- Create an organisation-level IAM Permission granting the above IAM Role to the Principal of the above service account.
The discrimiNAT automatically logs config & flow events to StackDriver. The following permission allows its instances to log at
logName="projects/<google-cloud project name>/logs/discriminat-config" and
logName="projects/<google-cloud project name>/logs/discriminat-flow".
To form a complete picture of the VM instances in the VPC and their associated Firewall Rules, the discrimiNAT needs read access to these resources.
In addition to the above, to discover VM instances in service projects, the following permission is required. See the Shared VPC page for more information.
SERVERLESS VPC ACCESS CONNECTORS
In addition to the above, the following will be required to form a complete picture of any Serverless VPC Access Connectors.
If permissions for Shared VPC are included, then any Serverless VPC Access Connectors defined in service projects will also be picked up.
See the Serverless VPC Access Connectors page for more information.
CLOUD COMPOSER v2 GKE CLUSTERS
A Composer v2 environment's cluster is an Autopilot mode VPC-native Google Kubernetes Engine cluster. Network Tags to it, however, can be applied at the time of the Composer environment's creation. Add the following permissions to the service account's role to allow the discrimiNAT to apply corresponding Firewall Rules to the clusters' subnets.
If a Public IP is not found attached to a discrimiNAT instance, it will look for any allocated but unassociated External IPs that have a label-key named
discriminat (set to any value.) One of such External IPs will be attempted to be associated with itself then.
This allows you to have a stable set of static IPs to share with your partners, who may wish to allowlist/whitelist them.
Private Google Access enabled on the subnet discrimiNAT is deployed in is needed for this mechanism to work though – since making the association needs access to the Compute API. In the google_network example, this is demonstrated by setting
subnet_private_access = true.
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
Does discrimiNAT work without a custom service account?
Yes. It can work with the default compute engine service account with limited scopes of
logging-write, if Shared VPC and Serverless VPC Access Connectors support is not required.
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.