Skip to main content

Service Account

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.

TL;DR

For all features and topologies enabled,

  1. Create an IAM service account, in a host project, for use by discrimiNAT instances.
  2. Create an organisation-level IAM Role with the following permissions.
  3. Create an organisation-level IAM Permission granting the above IAM Role to the Principal of the above service account.
logging.logEntries.create
compute.firewalls.list
compute.instances.list
compute.addresses.list
compute.addresses.use
compute.subnetworks.useExternalIp
compute.instances.addAccessConfig
compute.projects.get
vpcaccess.connectors.list
compute.subnetworks.get
container.clusters.list

LOGGING

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".

logging.logEntries.create

ALLOWLIST CONFIG

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.

compute.firewalls.list
compute.instances.list

SHARED VPC

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.

compute.projects.get

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.

vpcaccess.connectors.list
compute.subnetworks.get

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.

container.clusters.list
compute.subnetworks.get

EXTERNAL IPs

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.

tip

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.

compute.addresses.list
compute.addresses.use
compute.subnetworks.useExternalIp
compute.instances.addAccessConfig

Terraform

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 compute-rw and logging-write. If set to the Principal of any service account, assigns that service account to the instances and changes the scope to cloud-platform.

FAQ

Does discrimiNAT work without a custom service account?

Yes. It can work with the default compute engine service account with limited scopes of compute-rw and 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.