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.
- 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
deny constraints at the following levels
of the resource hierarchy:
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
Interaction between allowed and denied values
- If a
restrictCloudNatUsageconstraint is configured but neither
deniedValuesis specified, everything is allowed.
allowedValuesis configured and
deniedValuesis not configured, everything not specified in
deniedValuesis configured and
allowedValuesis not configured, everything not specified in
- If both
deniedValuesare configured, everything not specified in
- If two values conflict,
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
- A gateway exists in a region.
- The gateway is configured to allow all subnets in a region to use it.
- A single subnet (
subnet-1) exists in the region.
- A constraint is created so that only
subnet-1can use the gateway.
- 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
- Two subnets (
subnet-2) exist in a region.
- A constraint exists that only allows
subnet-1to use a gateway.
- 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-2to the list of permitted subnets.
Creating your constraints
To create an organization policy with a particular constraint, see Using constraints.