Google Cloud Organization Policy Guide: Constraints and Guardrails

In Google Cloud, IAM decides who can act on a resource, but nothing in IAM stops an authorised engineer from creating a service account key, a public bucket or a VM with an external IP unless the Organization Policy Service says no. Organization policies are the preventive guardrails of a Google Cloud organization: each one enforces a single constraint on an organization, folder or project and is inherited down the resource hierarchy. This guide explains the constraint types (managed, legacy managed and custom), how inheritance and merging really work, how to test with dry-run and Policy Simulator, where IAM deny policies fit, and how to roll guardrails out and measure them. It is written for platform engineers, cloud security architects and auditors who run or assess a Google Cloud organization.

Key takeaways

• Organization policy governs what, IAM governs who. Google describes the split explicitly: constraints restrict how resources can be configured, while allow and deny policies control which principals can act.
• Know which constraint family you are using. Managed constraints (for example iam.managed.disableServiceAccountKeyCreation) are replacing legacy managed constraints, are not merged on inheritance, and can be simulated; legacy list constraints merge with DENY taking precedence.
• Policies are not retroactive. A new policy blocks future create and update calls; existing public IPs, keys and buckets stay until you find and fix them.
• Test before you enforce. Use dry-run policies (dryRunSpec) and Policy Simulator to see violations before switching a policy live, and expect up to 15 minutes for changes to propagate.
• Protect the exception path. Anyone with Organization Policy Administrator, or who can bind the tags your conditions rely on, can create an exception; treat both as privileged.

Where organization policy sits in the resource hierarchy

The organization resource is the root, folders group projects beneath it, and projects contain service resources such as Compute Engine instances and Cloud Storage buckets. Organization, folder and project resources are all inheritance points for IAM allow policies, IAM deny policies and organization policies, so a policy set on a folder applies to every project in it. A resource's effective policy combines what is set on it directly with what it inherits.

A well-designed folder structure (for example, separate folders for shared platform services, production, non-production and sandbox) lets you apply strict guardrails at the organization node and grant narrow exceptions lower down. For landing zone structure across clouds, see the Cloud Landing Zone Security Guide.

Constraint types: managed, legacy managed and custom

A constraint is a blueprint for a restricted behaviour; an organization policy enforces exactly one constraint in active mode, dry-run mode or both. Google currently uses three names.

Managed constraints are designed to replace their legacy equivalents, and Policy Simulator supports managed and custom constraints but not legacy ones. When both versions of a control exist, prefer the managed one for new work and plan migration of the legacy policy.

Constraints worth knowing

Google's baseline for organizations created on or after 3 May 2024 enforces seven constraints (the key creation, key upload, default service account grant, identity domain, contact domain, protocol forwarding and uniform bucket-level access constraints). Older organizations have none of these unless someone set them, which is the first thing to check with gcloud resource-manager org-policies list --organization=ORGANIZATION_ID. The service account constraints matter most for non-human identity risk: see the Google Cloud IAM and Service Accounts Guide.

How inheritance and merging work

• Override by default: a resource with its own policy supersedes what its parents set, unless it sets inheritFromParent to true.
• List merging: with inheritFromParent = true, parent and child allowed and denied values are combined. Google states that DENY values always take precedence, so a folder deny cannot be undone by a project allow.
• Booleans do not merge: the value set on the most specific resource wins. A project with enforced: false ignores a folder's enforced: true, which is why the right to set project-level policy is effectively the right to opt out.
• Managed constraints do not merge: a child inherits as set or overrides entirely.
• Defaults are never merged: any explicit policy replaces the constraint's default. RestoreDefault returns a resource to the default behaviour, and its children inherit that.
• Automatically enforced defaults: some constraints restrict an operation even with no policy set, because Google's managed default is restrictive.

Custom constraints

Custom constraints let you enforce conditions Google does not ship, using Common Expression Language (CEL) against the resource's REST representation.

• Fields: name with the custom. prefix (ID up to 70 letters and numbers), resourceTypes such as container.googleapis.com/NodePool, methodTypes (CREATE and, for supported resources, UPDATE), condition (CEL, up to 1,000 characters), actionType ALLOW or DENY, displayName and description. The description is shown to the user as the error message, so write it as instructions.
• ALLOW versus DENY: DENY blocks the operation when the condition is true; ALLOW permits it only when the condition is true and blocks everything else. ALLOW is stricter and easier to get wrong.
• Lifecycle: create or update with gcloud org-policies set-custom-constraint. There is no versioning, so an update overwrites the constraint, and changes to an already enforced custom constraint take effect immediately. Deleting a constraint deletes the policies that use it.
• Limits and pitfalls: most resource types allow up to 20 custom constraints. Referencing a missing list index or map key returns BAD_CONDITION, which blocks resource creation, so guard expressions with has() or size(). Custom constraints are evaluated before predefined ones.

Policy as code applies here as in any engine: keep constraint YAML in a repository, review it, and test it. See the Policy-as-Code for Authorisation Guide.

Conditional enforcement with tags

Rules can carry conditions that match tags: resource.matchTag('123456789012/env', 'prod'), the ID form resource.matchTagId(), or key-only matches with resource.hasTagKey() and resource.hasTagKeyId(). A condition may combine up to 10 subexpressions. Organization, folder and project tags work with any constraint type; tags on service resources work only with certain legacy constraints such as gcp.resourceLocations and sql.restrictPublicIp.

• List constraints: conditional rules merge with the rest of the policy and apply only when the condition is true.
• Boolean constraints: a policy with a conditional rule needs exactly one unconditional rule, and the conditional rule must be its opposite (for example, enforced everywhere, not enforced where sandbox=true).
• Security consequence: if a tag grants an exception, the ability to bind that tag value is the ability to switch the guardrail off. Restrict tag binding for exception tags to the platform team.

IAM deny policies alongside organization policy

IAM deny policies block named principals from specific permissions regardless of the roles they hold, and Google states that IAM checks deny policies before allow policies. They attach to organizations, folders and projects, apply to all descendants, and a lower-level policy cannot override a broader deny. Rules use deniedPrincipals, exceptionPrincipals, deniedPermissions in the v2 format (for example iam.googleapis.com/roles.delete), exceptionPermissions and optional denialConditions, which can only use tag functions. Each resource can hold up to 500 deny policies with a combined 500 rules.

When to use which: use organization policy when the risk is a resource configuration (public bucket, external IP, key creation); use a deny policy when the risk is a principal performing a sensitive action (deleting projects, changing IAM on production folders, creating service account keys outside a break-glass group). The two layer well: a constraint blocks a risky configuration for everyone, while a deny policy with an exceptionPrincipals entry for a break-glass group stops everyone else from performing the related sensitive action. Check the list of permissions supported in deny policies before designing a rule, because not every permission can be denied. See the Multi-Cloud Identity Guide for how this compares to AWS SCPs and Azure Policy.

How to implement: a phased rollout

1. Inventory current state. List effective policies at the organization node and key folders, note whether your organization predates the May 2024 baseline, and record which projects already set their own overrides.
2. Agree the guardrail set. Start from the default seven and Google's blueprint list, then add location, CMEK or service-specific controls your regulators require. Write down, for each, the owner and the exception route.
3. Dry-run first. Apply each policy with gcloud org-policies set-policy POLICY_PATH --update-mask=dryRunSpec. Dry-run violations are audit-logged but not denied; Google suggests watching them over 30 days.
4. Simulate against existing resources. For managed and custom constraints, run gcloud policy-intelligence simulate orgpolicy --organization=ORGANIZATION_ID --policies=POLICY_PATH. This needs roles/policysimulator.orgPolicyAdmin, times out after four hours and keeps results for 14 days.
5. Fix existing violations. Because policies are not retroactive, remove existing keys, public IPs and public grants, or record a time-limited exception.
6. Enforce in rings. Switch to --update-mask=spec on a sandbox folder, then non-production, then production, allowing 15 minutes for propagation each time and running real deployment pipelines in between.
7. Grant exceptions narrowly. Set exceptions on the smallest project or folder that needs them, preferably through a tag condition owned by the platform team, and review them on a schedule.
8. Roll back safely. Keep every policy and custom constraint in source control. Roll back by reapplying the previous spec or moving the change back to dry-run, rather than deleting the policy, which would restore defaults for every descendant.

Decision guidance by organisation size

• Small organizations (one platform team, few projects): set the default seven plus public access prevention, OS Login, no default network and no external IPs at the organization node; keep a sandbox folder with conditional relaxations. Custom constraints can wait.
• Large or regulated organizations: manage policies through a pipeline (Google's terraform-example-foundation includes a policy library that validates changes before deployment), separate the people who write constraints from those who approve exceptions, add location and CMEK constraints, and use deny policies to protect the policy layer itself.
• Managed versus custom: prefer a Google managed constraint when one exists; it is maintained and simulatable. Use custom constraints for gaps, and budget for testing because there is no versioning.
• Organization node versus folder: set universal controls at the organization node; set environment-specific controls (external IPs allowed for a public edge folder, for example) on folders rather than scattering project overrides.

Where identity fits

Several of the most valuable constraints are identity controls in disguise: key creation and key upload constraints stop long-lived service account credentials, the default service account constraint removes automatic Editor grants, and domain restricted sharing stops roles being granted to outside accounts. The administrative roles are also identity risks: roles/orgpolicy.policyAdmin on the organization can remove any guardrail, so assign it to few principals, use it through just-in-time elevation, and keep it away from CI service accounts that do not need it. See the Cloud Workload Identity Guide.

Detection and measurement

• Policy changes: Organization Policy writes Admin Activity audit logs under orgpolicy.googleapis.com for CreatePolicy, UpdatePolicy, DeletePolicy and the custom constraint methods. Alert on any of them made outside your pipeline, for example with the filter protoPayload.serviceName="orgpolicy.googleapis.com".
• Dry-run results: review dry-run violations in audit logs before every promotion to live.
• Hierarchy changes: project moves between folders change inherited policy; ATT&CK tracks this as T1666 Modify Cloud Resource Hierarchy.

For log routing and retention, see the Cloud Logging and Audit Trail Guide.

Common failure patterns

• Assuming the baseline exists: organizations created before May 2024 do not have the secure-by-default constraints, so service account key creation is still open unless someone closed it.
• Believing a new policy cleaned up the estate: enforcement blocks new configurations only; old keys, public Cloud SQL instances and external IPs keep working until removed.
• Project-level opt-outs: because boolean policies do not merge, a project owner with policy rights can set enforced: false and quietly leave the guardrail.
• Exception tags anyone can bind: a tag condition that relaxes a constraint becomes a self-service bypass if tag binding is broadly granted.
• Brittle custom constraints: an unguarded CEL expression returns BAD_CONDITION and blocks every create of that resource type; an ALLOW constraint with a narrow condition blocks legitimate work.
• Half the control: blocking external IPv4 on VMs without addressing IPv6, or restricting public IP on Cloud SQL without authorised networks. See the Cloud Misconfiguration Guide.

Framework mapping

Practitioner checklist

• Confirm which of the seven baseline constraints are enforced at your organization node and enforce any that are missing.
• Add public access prevention, OS Login, no default network, no VM external IPs (IPv4 and IPv6) and Cloud SQL public IP restrictions.
• Prefer managed constraints over legacy equivalents for new policies and plan migration of existing ones.
• Run every new or changed policy in dry-run and, where supported, Policy Simulator before enforcement.
• Find and remediate pre-existing violations, since policies are not retroactive.
• Keep exceptions at folder or project level through platform-owned tags, each with an owner and review date.
• Limit Organization Policy Administrator to a few principals with just-in-time access and alert on policy changes outside the pipeline.
• Protect critical actions such as project deletion and IAM changes on production folders with IAM deny policies.
• Store constraints and policies as code, guard CEL with has() and size(), and roll back by reapplying the previous spec.

Standards and references

• Google Cloud: Introduction to the Organization Policy Service
• Google Cloud: Understanding hierarchy evaluation
• Google Cloud: Creating and managing custom constraints
• Google Cloud: Manage secure-by-default organization resources
• Google Cloud: Deny policies
• Google Cloud: Test organization policy changes with Policy Simulator
• Google Cloud: Enterprise foundations blueprint, preventative controls
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Google Cloud Security Guide · AWS Organizations and SCPs Guide · Azure Policy and Management Groups Guide · Cloud Security Guide · Cloud IAM Review Checklist