The Organization Policy Service gives you centralized and programmatic control over yourorganization's cloud resources. As theorganization policy administrator,you can configure constraints across your entireresource hierarchy.

Benefits

• Centralize control to configure restrictions on how your organization'sresources can be used.
• Define and establish guardrails for your development teams to stay withincompliance boundaries.
• Help project owners and their teams move quickly without worry of breakingcompliance.

Common use cases

Organization policies allow you to do the following:

• Limit resource sharing based on domain.
• Limit the usage of Identity and Access Management (IAM) service accounts.
• Restrict the physical location of newly created resources.

There are many more constraints that give you fine-grained control of yourorganization's resources. For more information, see thelist of all Organization Policy Service constraints.

Differences from Identity and Access Management

Identity and Access Management focuses onwho, and lets the administratorauthorize who can take action onspecific resources based on permissions.

Organization Policy focuses onwhat, and lets the administrator setrestrictions on specific resources to determine how they can be configured.

How organization policy works

An organization policy configures a singleconstraint thatrestricts one or more Google Cloud services. The organization policy isset on an organization, folder, or project resource to enforce the constraint onthat resource and any child resources.

An organization policy contains one or morerules that specify how, andwhether, to enforce the constraint. For example, an organization policy couldcontain one rule that enforces the constraint only on resources taggedenvironment=development, and another rule that prevents the constraint frombeing enforced on other resources.

Descendants of the resource to which the organization policy is attachedinherit the organization policy. By applying an organizationpolicy to the organization resource, the organization policy administrator cancontrol enforcement of that organization policy and configuration ofrestrictions across your organization.

Constraints

A constraint is a particular type of restriction against aGoogle Cloud service or a listof Google Cloud services. Think of the constraint as a blueprint thatdefines what behaviors are controlled. For example, you can restrict projectresources from accessing Compute Engine storage resources using thecompute.storageResourceUseRestrictions constraint.

This blueprint is then set on a resource in yourresource hierarchyas an organization policy, which applies the rules defined in the constraint.The Google Cloud service mapped to that constraint and associated withthat resource enforces the restrictions configured within the organizationpolicy.

An organization policy is defined in a YAML or JSON file by the constraint itenforces and optionally by the conditions under which the constraint isenforced. Each organization policy enforces exactly one constraint in activemode, dry-run mode, or both.

Managed constraints have list or boolean parameters that are determined bythe enforcing Google Cloud service.

Custom constraints are functionally similar to managed constraints with booleanparameters, and are either enforced or not enforced.

Legacy managed constraints have one or more list rules or boolean rules based onthe constraint type. List rules are a collection of allowed or denied values.Boolean rules can allow all values, deny all values, or determine if aconstraint is enforced or not enforced.

Managed constraints

Managed constraints are designed to replace equivalent legacy managedconstraints, but with additional flexibility and greater insight fromPolicy Intelligence tools. These constraintshave similar structure to custom organization policy constraints, but aremanaged by Google.

If the equivalent legacy managed constraint has a constraint type of boolean,the managed constraint can either be enforced or not in the same way. Forexample, the following organization policy enforcesiam.managed.disableServiceAccountCreation, which is the equivalent constrainttoiam.disableServiceAccountCreation:

name:organizations/1234567890123/policies/iam.managed.disableServiceAccountCreationspec:rules:-enforce:true

If the equivalent legacy managed constraint has a constraint type of list, themanaged constraint supports defining parameters that define the resources andbehaviors that are restricted by the constraint. For example, the followingorganization policy enforces a managed constraint that only allows theexample.com andaltostrat.com domains to be added toEssential Contacts fororganizations/1234567890123:

name:organizations/1234567890123/policies/essentialcontacts.managed.allowedContactDomainsspec:rules:-enforce:trueparameters:allowedDomains:-@example.com-@altostrat.com

To learn more about using managed constraints, seeUsing constraints.

Custom constraints

Like managed constraints, custom constraints allow or restrict resource creationand updates. However, custom constraints are managed by your organizationinstead of by Google. You can usePolicy Intelligence tools to test and analyzeyour custom organization policies.

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

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

For a list of sample custom constraints, see thecustom organization policy library on GitHub.

Managed constraints (legacy)

Legacy managed constraints have aconstraint type of list or boolean, whichdetermines the values that can be used for checking enforcement. The enforcingGoogle Cloud service will evaluate the constraint type and value todetermine the restriction that is enforced.

These legacy constraints were previously known aspredefined constraints.

List rules

Legacy managed constraints with list rules allow or disallow a list of valuesthat are defined in an organization policy. These legacy constraints werepreviously known aslist constraints. The list of allowed or denied values isexpressed as a hierarchy subtree string. The subtree string specifies the typeof resource it applies to. For example, the legacy managed constraintconstraints/compute.trustedImageProjects takes a list of project IDs in theform ofprojects/PROJECT_ID.

You can specify that all values are allowed, all values are denied, or that aspecific list of values are either allowed or denied. When you specify a listof allowed or denied values, Organization Policy Service implicitly evaluates that onlythose values are allowed or denied. For example, if you have a constraint thatallows onlyprojects/PROJECT_ID, then all other values areimplicitly denied.

Values can be given a prefix in the formprefix:value for constraints thatsupport them, which gives the value additional meaning:

• is: - applies a comparison against the exact value. This is the samebehavior as not having a prefix, and is required when the value includes acolon.

• under: - applies a comparison to the value and all of its child values. Ifa resource is allowed or denied with this prefix, its child resources are alsoallowed 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. Forexample, you can addin:us-locations to the denied list of theconstraints/gcp.resourceLocations constraint to block all locations that areincluded in theus region.

If no list of values is provided, or the organization policy is set to theGoogle-managed default, then the default behavior of the constraint takeseffect, which either allows all values or denies all values.

The following organization policy enforces a legacy managed constraint thatallows the Compute Engine VM instancesvm-1 andvm-2 inorganizations/1234567890123 to access external IP addresses:

name:organizations/1234567890123/policies/compute.vmExternalIpAccessspec: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 rules

A legacy managed constraint with a boolean rule is either enforced or notenforced. For example,constraints/compute.disableSerialPortAccess has twopossible states:

• Enforced - the constraint is enforced, and serial port access is notallowed.
• Not enforced - thedisableSerialPortAccess constraint is not enforced orchecked, so serial port access is allowed.

If the organization policy is set to the Google-managed default, then thedefault behavior for the constraint takes effect.

These legacy constraints were previously known asboolean constraints.

The following organization policy enforces a legacy managed constraint thatdisables the creation of external service accounts inorganizations/1234567890123:

name:organizations/1234567890123/policies/iam.disableServiceAccountCreationspec:rules:-enforce:true

Organization policies in dry-run mode

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

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

Conditional organization policies

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

For more information about tags, seeTags overview. To learn how to seta conditional organization policy using tags, seeSetting an organization policy with tags.

Inheritance

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

You can set an organization policy on a descendant resource that eitheroverwrites the inheritance or inherits the organization policy of the parentresource. Organization policies that enforce legacy managed constraints aremerged based on the rules of hierarchy evaluation. This system provides precisecontrol for how your organization policies apply throughout your organizationand where you want exceptions made.

Note: Managed constraints that are inherited from a parent resource aren't merged to evaluate the effective policy on a given resource. A resource that inherits a managed constraint enforces the constraint as it was set on the parent resource or overrides the constraint with its own policy.

To learn more, seeUnderstanding hierarchy evaluation.

Violations

A violation is when a Google Cloud service acts or is in a state that iscounter to the organization policy restriction configuration within the scope ofits resource hierarchy. Google Cloud services will enforce constraints toprevent violations, but the application of new organization policies is usuallynot retroactive. If an organization policy constraint is retroactivelyenforced, it will be labeled as such on theorganization policy constraintspage.

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

Policy Intelligence

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

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

• Test changes toorganization policies and constraints and identify resources that arenon-compliant under the proposedpolicy (Preview).
• Create a dry-run organization policyto monitor how a policy change would affect your workflows.
• Analyze existing organization policiesto understand which Google Cloud resources are covered by whichorganization policy.

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

Next steps

• Read theCreating and managing organization resourcespage to learn how to acquire an organization resource.
• Learnhow to define organization policies.
• Explore thesolutions you can accomplishwith organization policy constraints.