Introduction to the Organization Policy Service

The Organization Policy Service gives you centralized and programmatic control over your organization's cloud resources. As the organization policy administrator, you can configure constraints across your entire resource hierarchy.

Benefits

  • 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.

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 list of all Organization Policy Service constraints.

Differences from Identity and Access Management

Identity and Access Management focuses on who, and lets the administrator authorize 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 constraint 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 inherit 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.

Organization policy concepts

Constraints

A constraint is a particular type of restriction against a Google Cloud service 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 resource hierarchy 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:

  • 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.

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:

  • 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.

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 custom organization policy platform. The custom organization policy platform allows for organization policies to be designed with more flexibility, and with greater insight from Policy Intelligence tools.

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

To learn more about using managed constraints, see Using constraints.

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 Policy Intelligence tools to test and analyze your custom organization policies.

For a list of service resources that support custom constraints, see Custom constraint supported services.

To learn more about using custom organization policies, see Creating and managing custom organization policies.

Organization policies in dry-run mode

An organization policy in dry-run mode is created and enforced similarly to other organization policies, and violations of the policy are audit-logged, but the violating actions aren't denied.

You can use organization policies in dry-run mode to monitor how policy changes would impact your workflows before it is enforced. For more information, see Create an organization policy in dry-run mode.

Conditional organization policies

Tags provide a way to conditionally enforce constraints based on whether a resource has a specific tag. You can use tags and conditional enforcement of constraints to provide centralized control of the resources in your hierarchy.

For more information about tags, see Tags overview. To learn how to set a conditional organization policy using tags, see Setting an organization policy with tags.

Inheritance

When an organization policy is set on a resource, all descendants of that resource inherit the organization policy by default. If you set an organization policy on the organization resource, then the configuration of restrictions defined by that policy will be passed down through all descendant folders, projects, and service resources.

You can set an organization policy on a descendant resource that either overwrites the inheritance, or inherits the organization policy of the parent resource. In the latter case, the two organization policies are merged based on the rules of hierarchy evaluation. This provides precise control for how your organization policies apply throughout your organization, and where you want exceptions made.

To learn more, see Understanding hierarchy evaluation.

Violations

A violation is when a Google Cloud service acts or is in a state that is counter to the organization policy restriction configuration within the scope of its resource hierarchy. Google Cloud services will enforce constraints to prevent violations, but the application of new organization policies is usually not retroactive. If an organization policy constraint is retroactively enforced, it will be labeled as such on the organization policy constraints page.

If a new organization policy sets a restriction on an action or state that a service is already in, the policy is considered to be in violation, but the service won't stop its original behavior. You will need to address this violation manually. This prevents the risk of a new organization policy completely shutting down your business continuity.

Policy Intelligence

Policy Intelligence is a suite of tools designed to help you manage security policies. These tools can help you understand resource usage, understand and improve existing security policies, and prevent policy misconfigurations.

Some Policy Intelligence tools are specifically designed to help test and analyze Organization Policy Service policies. We recommend that you test and dry-run all changes to your organization policies. With Policy Intelligence, you can do tasks like the following:

To learn more about these tools and other Policy Intelligence tools, see Policy Intelligence overview.

Next steps