Skip to content
Centralize control to configure restrictions on how your organization's resources can be used.Define and establish guardrails for your development teams to stay within compliance boundaries.Help project owners and their teams move quickly without worry of breaking compliance.
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 allowed or denied. The value provided must be the ID of an organization, folder, or project resource.in: - applies a comparison to all resources that include this value. For example, you can add in:us-locations to the denied list of the constraints/gcp.resourceLocations constraint to block all locations that are included in the us region.
Enforced - the constraint is enforced, and serial port access is not allowed.Not enforced - the disableSerialPortAccess constraint is not enforced or checked, so serial port access is allowed.
Organization policies
The Organization Policy Service gives you centralized and programmatic control over your organization's cloud resources. As the , you can configure constraints across your entire .
Benefits
Common use cases
Organization policies allow you to do the following:
There are many more constraints that give you fine-grained control of your organization's resources. For more information, see the .
Differences from Identity and Access Management
focuses on who, and lets the administrator who can take action on specific resources based on permissions.
Organization Policy focuses on what, and lets the administrator set restrictions on specific resources to determine how they can be configured.
How organization policy works
An organization policy configures a single that restricts one or more Google Cloud services. The organization policy is set on an organization, folder, or project resource to enforce the constraint on that resource and any child resources.
An organization policy contains one or more rules that specify how, and whether, to enforce the constraint.
For example, an organization policy could contain one rule that enforces the constraint only on resources tagged environment=development, and another rule that prevents the constraint from being enforced on other resources.
Descendants of the resource to which the organization policy is attached the organization policy. By applying an organization policy to the organization resource, the organization policy administrator can control enforcement of that organization policy and configuration of restrictions across your organization.
Constraints
A constraint is a particular type of restriction against a or a list of Google Cloud services. Think of the constraint as a blueprint that defines what behaviors are controlled. For example, you can restrict project resources from accessing Compute Engine storage resources using the compute.storageResourceUseRestrictions constraint.
This blueprint is then set on a resource in your as an organization policy, which applies the rules defined in the constraint. The Google Cloud service mapped to that constraint and associated with that resource enforces the restrictions configured within the organization policy.
An organization policy is defined in a YAML or JSON file by the constraint it enforces, and optionally by the conditions under which the constraint are enforced. Each organization policy enforces exactly one constraint in active mode, dry-run mode, or both.
Predefined constraints have a constraint type of list or boolean, which determines the values that can be used for checking enforcement. The enforcing Google Cloud service will evaluate the constraint type and value to determine the restriction that is enforced.
Custom constraints are functionally similar to boolean constraints, and are either enforced or not enforced.
Managed constraints have list or boolean parameters. The available parameters are determined by the enforcing Google Cloud service.
List constraints
A list constraint is a predefined constraint that 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, the list constraint constraints/compute.trustedImageProjects takes a list of project IDs in the form of projects/PROJECT_ID.
Values can be given a prefix in the form prefix:value for constraints that support them, which gives the value additional meaning:
If no list of values is provided, or the organization policy is set to the Google-managed default, then the default behavior of the constraint takes effect, which either allows all values or denies all values.
The following organization policy enforces a list constraint that allows the Compute Engine VM instances vm-1 and vm-2 in organizations/1234567890123 to access external IP addresses:
name: organizations/1234567890123/policies/compute.vmExternalIpAccess
spec:
rules:
- values:
allowedValues:
- is:projects/project_a/zones/us-central1-a/instances/vm-1
- is:projects/project_b/zones/us-central1-a/instances/vm-2
Boolean constraints
A boolean constraint is a predefined constraint that is either enforced or not enforced. For example, the predefined constraint constraints/compute.disableSerialPortAccess has two possible states:
If the organization policy is set to the Google-managed default, then the default behavior for the constraint takes effect.
The following organization policy enforces a predefined constraint that disables the creation of external service accounts in organizations/1234567890123:
name: organizations/1234567890123/policies/iam.disableServiceAccountCreation
spec:
rules:
- enforce: true
Managed constraints
Managed constraints are constraints that have been built on the platform. The custom organization policy platform allows for organization policies to be designed with more flexibility, and with greater insight from .
Managed constraints are designed to replace equivalent predefined constraints. If the equivalent predefined constraint has a constraint type of boolean, the managed constraint can either be enforced or not in the same way. For example, the following organization policy enforces iam.managed.disableServiceAccountCreation, which is the equivalent constraint to iam.disableServiceAccountCreation:
name: organizations/1234567890123/policies/iam.managed.disableServiceAccountCreation
spec:
rules:
- enforce: true
If the equivalent predefined constraint has a constraint type of list, the managed constraint supports defining parameters that define the resources and behaviors that are restricted by the constraint. For example, the following organization policy enforces a managed constraint that only allows the example.com and altostrat.com domains to be added to Essential Contacts for organizations/1234567890123:
name: organizations/1234567890123/policies/essentialcontacts.managed.allowedContactDomains
spec:
rules:
- enforce: true
parameters:
allowedDomains:
- @example.com
- @altostrat.com
Custom constraints
Custom constraints allow or restrict resource creation and updates in the same way that boolean constraints do, but allow administrators to configure conditions based on request parameters and other metadata. You can use to test and analyze your custom organization policies.
For a list of service resources that support custom constraints, see .
Ref:
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.