Organization policy constraints

This page provides information about the organization policy constraints that you can configure for Cloud NAT.

Network administrators can create Cloud NAT configurations and specify which subnetworks (subnets) can use the gateway. By default, there are no limits to what subnets the administrator creates or which of them can use a Cloud NAT configuration.

An Organization Policy Administrator (roles/orgpolicy.policyAdmin) can use the constraints/compute.restrictCloudNATUsage constraint to limit which subnets can use Cloud NAT.

You create and enforce organizational constraints in an organization policy.


IAM permissions

  • The person creating the constraints must have the roles/orgpolicy.policyAdmin role.
  • If using Shared VPC, the user role must be in the host project.

Organization policy background

If you have not worked with organization policy constraints before, first review the following documentation:

Planning your constraints

You can create allow or deny constraints at the following levels of the resource hierarchy:

  • Organization
  • Folder
  • Project
  • Subnetwork

By default, a constraint created at a node is inherited by all child nodes. However, an Organization Policy Administrator for a given folder can decide if a given folder inherits from its parents, so inheritance is not automatic. For more information, see Inheritance in Understanding hierarchy evaluation.

Constraints are not applied retroactively. Existing configurations continue to work even if they violate the constraints.

Constraints consist of allow and deny settings.

Interaction between allowed and denied values

  • If a restrictCloudNatUsage constraint is configured but neither allowedValues nor deniedValues is specified, everything is allowed.
  • If allowedValues is configured and deniedValues is not configured, everything not specified in allowedValues is denied.
  • If deniedValues is configured and allowedValues is not configured, everything not specified in deniedValues is allowed.
  • If both allowedValues and deniedValues are configured, everything not specified in allowedValues is denied.
  • If two values conflict, deniedValues takes precedence.

Interaction between subnets and gateways

Constraints do not prevent subnets from using a NAT gateway. Instead, constraints prevent a configuration that would violate the constraint by preventing the creation of either a gateway or a subnet.

Example 1: Trying to create a subnet that violates a deny rule

  1. A gateway exists in a region.
  2. The gateway is configured to allow all subnets in a region to use it.
  3. A single subnet (subnet-1) exists in the region.
  4. A constraint is created so that only subnet-1 can use the gateway.
  5. Administrators are not able to create more subnets in that network in that region. The constraint prevents the creation of subnets that would be able to use the gateway. If the new subnets should exist, then the Organization Policy Administrator can add these subnets to the list of permitted subnets.

Example 2: Trying to create a gateway that violates a deny rule

  1. Two subnets (subnet-1 and subnet-2) exist in a region.
  2. A constraint exists that only allows subnet-1 to use a gateway.
  3. Administrators are not able to create a gateway that is open to all subnets in the region. Instead, either they have to create a gateway that only serves subnet-1, or the Organization Policy Administrator has to add subnet-2 to the list of permitted subnets.

Creating your constraints

To create an organization policy with a particular constraint, see Using constraints.

What's next