Understanding Constraints

A constraint is a definition for the way in which a resource's configuration can be restricted.

It is important to understand that constraints are defined and enforced by the service to which they apply; Constraints are configured to your needs, through the use of policies, by your organization's policy administrator. Therefore, you will not create constraints, but will create policies that define how constraints are applied by your organization.

At a high level, a constraint defines a schema for a policy. This includes the type of the restriction (list or boolean), and the evaluation scheme used by the service when checking the policy, such as whether to allow or deny items from a list and the behavior when no policy is present in the resource hierarchy. A policy is a realization of a restriction for a particular constraint, enforcing future conformance to that restriction at a particular resource.

Constraints can be one two types: list or boolean. Each of these is described in more detail below. All constraints have the following values:

  • Name: an immutable string that is required to be unique. For example, constraints/serviceuser.services.
  • Display name: a mutable human-readable name.
  • Description: a detailed description of what instantiations of this constraint control, as well as how and where they are enforced.
  • Constraint default: the default behavior in the absence of any policy derived from the constraint. For list constraints, if the value is ALLOW, then all values are allowed. If the value is DENY, then all values will be denied. For boolean constraints, when ALLOW is set then enforcement is off, meaning everything is allowed. When DENY is set for the constraint, it is enforced.

List constraints

A list constraint is a constraint that allows/disallows a list of string values. The list of string values are configured by your Organization's policy administrator in a policy. A list constraint that specifies a list of string values to be allowed or disallowed as specified in a policy derived from the constraint.

The default evaluation of a list constraint is to enforce the restrictions set at the current node. Your policy administrator can override this behavior in the policy, by setting the policy's inherit_from_parentvalue to True, allowing for merge semantics.

Boolean constraints

A boolean constraint is a constraint that is either enforced or not.

For example, suppose we have a constraint, constraints/compute.disableSerialPortAccess, with constraint_default = ALLOW. Then a policy for that constraint exhibits the following behavior:

  • If no policy exists in the hierarchy, serial port access is allowed.
  • If the policy with the enforced field is set to False then serial port access is allowed.
  • If the policy with the enforced field is set to True then serial port access is not allowed.
  • If the policy with the enforced field is set to RestoreDefault then serial port access is allowed.

Available constraints

You can specify policies that use the following constraints. More constraints are under development.

Service(s) Constraint Description
Compute Engine Disable VM Serial Port Access Disables serial port access to Compute Engine VMs belonging to the organization, project, or folder where this constraint is set to True.
Compute Engine - Trusted Image Projects A policy for this constraint defines the trusted projects that provide boot disk images for your Compute instances. If a policy is defined in the ancestral path (i.e. owning project, folders, and organization), then only images from trusted projects will be allowed as boot disks for a newly created instance. If no policy is set in the ancestral path then any public image and shared custom image may be used to create a boot disk. The allowed/denied list of publisher projects is a list of strings in the following form: projects/[PROJECT_ID].
External IPs For VM instances This constraint defines a set of Compute Engine VM instances that are allowed to use external IP addresses. By default, if no policy is specified, all VM instances are allowed to use external IP addresses. VM instances specified in the allowed or denied lists must be identified by the VM instance name, in the form: projects/[PROJECT_ID]/zones/[ZONE]/instances/[INSTANCE].
Resource Manager Restrict XPN Project Lien Removal When enforced, requires that the permission to remove an XPN project lien (resourcemanager.projects.updateLiens) is granted at the org. When not enforced, any user with the permission to update liens can remove an XPN project lien.
Google Cloud Platform APIs and Services Defines the set of services and their APIs that can be enabled on this resource and below. Only explicitly denied values from this list can be set in the policy. Adding APIs not in this list as a value will result in an error. Alternatively, the policy can be set to allow all services, which is the default behavior. The list of values include:

If no policy is set on a project or its ancestors for this constraint, all services and their APIs are allowed. Enforcement of this constraint is not retroactive: if a service is already enabled on a resource, calls to it will still work if a new policy is applied to a containing resource.

For complete details about constraints/compute.vmExternalIpAccess, refer to Disabling external IP access for VMs.

Next steps

Send feedback about...

Google Cloud Resource Manager Documentation