A constraint is a type of restriction against a GCP service or a list of GCP services. Think of the constraint as a blueprint that defines what behaviors are controlled. This blueprint is then applied to a resource hierarchy node as an organization policy, which implements the rules defined in the constraint. The GCP service mapped to that constraint and associated with that resource hierarchy node will then enforce the restrictions configured within the organization policy.
A constraint has a type, which determines the organization policy values that can be entered and used for checking enforcement. The enforcing GCP service will evaluate the constraint type and value to determine restriction.
During hierarchy evaluation, the organization policy
set on the current resource hierarchy node takes effect. If
inheritFromParent is set to
TRUE, then inheritance merging takes
Every constraint is defined by these attributes:
- Name: the unique name of the constraint.
- For example,
- For example,
- Display name: the human-friendly name of the constraint.
- Description: details on what enforcements are put in place and by which GCP services.
- Default behavior: behavior in the absence of user-defined configuration within the policy.
Types of constraints
A list constraint allows or disallows a
list of values that is defined in an organization policy. This list of values is
expressed as a hierarchy subtree string. The subtree string specifies the type
of resource it applies to. For example, a list of project IDs in the form of
The following table describes some common constraint configurations for policy enforcement:
|Allow a specific set of values||Set the allowed values field (
|Deny a specific set of values||Set the denied values field (
|Deny a value and all of its child values||Set the denied values field (
|Allow all valid values||Set
Do not set
|Deny all values||Set
Do not set
Values can also be given a prefix in the form “prefix:value”, which then gives the value additional meaning:
is:- Applies a comparison against the exact value. This is the same behavior as not having a prefix, and is required when the value includes a colon.
under:- Applies a comparison to the value and all of its child values. If a resource is allowed or denied with this prefix, its child resources are also denied. The value provided must be a subtree string, as in the following examples:
To see which constraints support using hierarchy subtree value prefixes, see Organization policy constraints.
Hierarchy subtree value prefixes are a beta feature, might be changed in backward-incompatible ways, and are not subject to any SLA or deprecation policy. For more information about using prefixed values in constraints, see Set up enforcement against a hierarchy subtree.
If no list of values is provided, then the default that takes effect, depending on the specific constraint, may be:
ALLOW- Any valid value is allowed.
DENY- No value is allowed.
A boolean constraint is either in
enforcement or not. The policy is enforced by setting
constraints/compute.disableSerialPortAccess will have two
- TRUE - the
disableSerialPortAccessconstraint is enforced, and serial port access is not allowed.
- FALSE - the
disableSerialPortAccessconstraint is not enforced or checked, so serial port access is allowed.
If no policy is set, or the policy is set to
RestoreDefault, then serial port
access is allowed because the constraint default is to allow.