Google Cloud Organisation Policy Explained: Constraints, Examples, and Use Cases

What is Organisation Policy?

Organisation Policy is a preventive security control that restricts which configurations and actions are allowed across your Google Cloud environment. It operates through the resource hierarchy (organisation, folders, and projects) and enforces rules that apply to every identity and resource within scope, regardless of what IAM permissions grant.

It complements IAM rather than replacing it. IAM controls who can act: it grants roles to users, service accounts, and groups. Organisation Policy controls what is allowed to happen at all. You need both: IAM scopes individual access rights, Organisation Policy blocks entire categories of risky behaviour across your environment.

The simple version

Imagine you manage 50 GCP projects across five teams. You want to ensure that nobody, regardless of their role, can create a service account key file, deploy a VM with an external IP, or create resources outside an approved region. You could try to manage this through IAM by carefully reviewing every role binding in every project. Or you can set three Organisation Policy constraints once, at the organisation level, and have them enforced automatically across every project now and in the future.

That is what Organisation Policy is for: centralised, hierarchy-wide guardrails that do not rely on per-project IAM configuration.

How Organisation Policy works

Organisation Policy works through constraints. Each constraint is a named rule that restricts or requires a specific behaviour. Google Cloud provides hundreds of built-in constraints. You do not create them from scratch. Instead, you enable, configure, and apply the ones that match your security requirements.

When you apply a constraint to a node in the resource hierarchy, it is inherited by everything below it:

• A constraint at the organisation level applies to every folder, project, and resource in the organisation.
• A constraint at a folder level applies to every project in that folder.
• A constraint at the project level applies only to that project.

When a user or service account attempts an operation, Google Cloud evaluates the effective policy for the target resource. If any inherited constraint blocks the operation, the action is rejected before any IAM check runs. A project Owner cannot bypass this, because the constraint is evaluated at a layer above IAM.

This makes Organisation Policy a preventive control. It stops risky actions from happening rather than detecting them after the fact. Cloud Audit Logs is the complementary detective control for observing what did happen.

IAM vs Organisation Policy

These two controls are often confused because both affect what a user can do. The distinction matters for designing a secure environment.

IAM is identity-scoped. You grant a role to a principal and that principal can take the actions the role permits. Preventing a misconfiguration through IAM alone means auditing every role in every project and ensuring no role grants the relevant permission, now and after every future permission change. That is unmanageable at scale.

Organisation Policy operates at the resource hierarchy level. You set a constraint once and it applies to every project and every identity within scope, including project Owners, Editors, and service accounts. Use IAM least privilege to limit what each identity can do. Use Organisation Policy to block entire classes of behaviour regardless of permissions.

Types of constraints

All built-in constraints fall into one of two types. Knowing the difference helps you choose and configure them correctly.

Boolean constraints

A boolean constraint is an on/off toggle for a specific behaviour. Set enforce: true to activate the restriction, or enforce: false to explicitly disable an inherited constraint at a lower level.

Use boolean constraints when the restriction applies uniformly. There are no partial allowances and no variation by value:

• iam.disableServiceAccountKeyCreation: key creation is blocked for all principals in scope, with no exceptions
• compute.requireOsLogin: OS Login is required on all VMs in scope
• compute.disableSerialPortAccess: serial port access is disabled on all VMs in scope
• compute.skipDefaultNetworkCreation: the default VPC is suppressed on all new projects in scope
• storage.uniformBucketLevelAccess: legacy ACLs are blocked on all buckets in scope

List constraints

A list constraint allows or denies a set of named values. Rather than a simple toggle, you define which values are permitted or which are prohibited. A child resource can merge values with its parent or override them entirely, depending on how the parent policy is configured.

Use list constraints when the restriction varies by value:

• gcp.resourceLocations: you specify which regions are allowed, not just whether location restrictions are active
• compute.vmExternalIpAccess: you specify which VMs (by resource name) may have external IPs, or deny all
• iam.allowedPolicyMemberDomains: you specify which Cloud Identity domains are permitted in IAM bindings
• compute.restrictCloudArmor.policies: restricts which Cloud Armor security policies can be applied

Inheritance and the override model

When you set a constraint on a folder, all projects inside that folder inherit it automatically. No per-project configuration is needed. Add a new project to a folder and it immediately operates under all constraints set on that folder and its parent nodes in the resource hierarchy.

Child resources can sometimes override inherited constraints:

• For boolean constraints, a child can set enforce: false to disable an inherited constraint unless the parent has marked the constraint non-overridable.
• For list constraints, a child can merge values with the parent or replace them, depending on how the parent policy is configured.

The practical design pattern: set strict baseline constraints at the organisation or production folder level. Mark critical constraints non-overridable. Allow specific projects to have documented project-level exceptions only where explicitly approved. This gives you broad coverage without preventing all flexibility.

To verify what is actually in effect for a project (including all inherited constraints), use the CLI commands in the section below. The constraint blocking an operation may have been set at a parent folder or organisation level rather than the project itself.

High-value constraints to enable early

These address the most common GCP security misconfigurations and are broadly safe to enforce once you have tested in a staging environment first.

iam.disableServiceAccountKeyCreation

Prevents creating long-lived JSON key files for service accounts. Key files are the most commonly leaked credential type in GCP environments. They get downloaded, committed to git repos, and shared over email. Enforcing this across production folders ensures all authentication uses attached workload identity, service account impersonation, or Workload Identity Federation.

iam.disableServiceAccountKeyUpload

Blocks uploading external key material to service accounts. This closes a workaround where someone generates a key pair externally and uploads the public component to a service account. Pair with iam.disableServiceAccountKeyCreation for full coverage against long-lived key abuse.

compute.requireOsLogin

Requires OS Login for SSH access to all Compute Engine VMs. When enforced, only users with the appropriate IAM role can SSH into a VM. There is no workaround through instance metadata SSH keys. This ties VM access directly into your Cloud Identity directory and IAM, making access centrally managed and auditable.

compute.disableSerialPortAccess

Disables the serial port console on VMs. Serial port access is useful for debugging but also allows interaction with a VM at a level that can bypass OS-level controls. Most production workloads do not need it, and the risk of leaving it enabled rarely justifies the convenience.

storage.uniformBucketLevelAccess

Requires all Cloud Storage buckets to use IAM-only access control, disabling legacy Access Control Lists (ACLs). Legacy ACLs are harder to audit and have produced unintended public access configurations in many environments. This constraint prevents bucket creation or modification using ACLs.

gcp.resourceLocations

Prevents resources from being created outside approved regions or multi-regions. Required for data residency compliance and reduces the risk of resources landing in unmonitored regions. See restricting resource locations for full configuration details and region value syntax.

iam.allowedPolicyMemberDomains

Restricts IAM bindings to identities from specific Cloud Identity or Google Workspace domains. Prevents users from granting access to arbitrary Gmail accounts or personal Google accounts that cannot be centrally managed or deprovisioned. Particularly important when team members informally add collaborators to projects.

compute.skipDefaultNetworkCreation

Prevents GCP from automatically creating the default VPC network in new projects. The default VPC comes with permissive firewall rules that allow SSH and RDP from any source. Requiring explicit network creation forces teams to configure networking deliberately rather than inheriting an insecure default.

compute.vmExternalIpAccess

Controls which VMs are allowed external IP addresses. In environments where workloads should only be accessible from within a private network, you can deny all external IPs or restrict to a specific approved list. This significantly reduces the internet-exposed attack surface.

When to use Organisation Policy

Organisation Policy is the right tool when you need a rule that applies to all projects and all identities without relying on per-project IAM configuration. Common use cases:

• Blocking service account key creation. Keys are the most commonly leaked GCP credential. Blocking them at org level removes the risk entirely for environments that have migrated to keyless authentication.

• Enforcing approved regions. Data residency requirements, compliance frameworks, and latency predictability all benefit from preventing resources from landing in unapproved regions.

• Reducing public exposure. Constraints like compute.vmExternalIpAccess and storage.uniformBucketLevelAccess reduce the surface area for unintentional public access across all projects simultaneously.

• Standardising new project defaults. Every new project added to a folder automatically inherits the folder’s constraints. No manual policy application is needed for each new project.

• Supporting compliance and governance. Many compliance frameworks require controls that can be proven to be in effect regardless of individual user action. Organisation Policy provides that assurance in a way that IAM alone cannot.

• Preventing insecure defaults. The default VPC, the default service account, and metadata-based SSH keys are GCP defaults that are convenient but insecure. Constraints force deliberate configuration.

A useful rule of thumb: if a security requirement can be violated by a sufficiently privileged IAM user, Organisation Policy should enforce it instead.

How to roll out Organisation Policy safely

Enforcing a constraint too broadly, too fast, is the most common Organisation Policy mistake. A staged rollout reduces risk significantly.

1. Start in a sandbox or staging folder. Apply the constraint to a low-impact scope and run your normal deployment and automation workflows. Observe what fails.

2. Test impact on CI/CD and Terraform. Automated pipelines are the most likely to break. If you manage infrastructure with Terraform, run a plan after applying the constraint to surface incompatibilities before they reach production.

3. Document required exceptions before enforcing. Identify any workloads that genuinely need the blocked behaviour. Create project-level policy exceptions with documented owners and review dates before the constraint goes live at a higher level.

4. Promote to production folders. Once confident in the staging outcome, apply the constraint to production folders and monitor for violations in Cloud Audit Logs.

5. Promote to organisation level if universally applicable. Some constraints (like disabling serial port access) are safe to apply everywhere. Others may require project-level exceptions for specific workloads.

6. Verify effective policy after each promotion. Run gcloud org-policies list —project=PROJECT_ID on representative projects to confirm the constraint is in effect as expected, including inherited constraints from parent folders.

Example policy workflow

A practical end-to-end flow for adding a new Organisation Policy constraint:

1. Identify the risky behaviour. For example, developers are creating service account keys in production projects for local testing.
2. Choose the correct constraint. iam.disableServiceAccountKeyCreation is a boolean constraint that blocks key creation for any principal in scope.
3. Apply to a staging folder first. Write a policy YAML file and apply it with gcloud org-policies set-policy targeting a non-production folder.
4. Run automation and deployments in that folder. Watch for failures. Determine whether each failure requires a code change, a workflow migration, or a documented exception.
5. Handle exceptions deliberately. For any workload that genuinely requires the blocked action, set a project-level exception with a documented owner, reason, and review date.
6. Promote to production folders and org level.
7. Monitor via audit logs. Policy violations are logged as ConstraintViolation events. Review these after rollout to catch unexpected behaviour.

CLI examples

Create a YAML file defining the policy, then apply it:

# policy.yaml: boolean constraint at project level
name: projects/my-app-prod/policies/iam.disableServiceAccountKeyCreation
spec:
  rules:
    - enforce: true

# Apply the policy from a YAML file
gcloud org-policies set-policy policy.yaml

Verify the effective policy on a specific project, including constraints inherited from parent folders:

gcloud org-policies describe iam.disableServiceAccountKeyCreation \
  --project=my-app-prod

List all effective policies on a project, including inherited ones:

gcloud org-policies list --project=my-app-prod

Check effective policies at the folder level:

gcloud org-policies list --folder=FOLDER_ID

Check where a constraint was originally set in the hierarchy:

gcloud org-policies describe compute.requireOsLogin \
  --organization=ORG_ID

Apply a list constraint to restrict allowed resource locations:

# locations-policy.yaml: list constraint at folder level
name: folders/FOLDER_ID/policies/gcp.resourceLocations
spec:
  rules:
    - values:
        allowedValues:
          - in:europe-west2-locations
          - in:europe-west1-locations

gcloud org-policies set-policy locations-policy.yaml

Managing exceptions

Some teams or workloads genuinely need exceptions to organisation-wide constraints. The correct approach is to set the constraint at a high level and override it at the specific project level for approved cases.

Every exception should include:

• Owner: a named team or individual responsible for the exception
• Reason: documented justification for why the standard constraint cannot apply
• Expiry or review date: a date by which the exception is re-evaluated or removed
• Audit trail: an entry in your exception tracking process so unexpected policy overrides are noticed quickly

Undocumented exceptions accumulate over time until the policy looks enforced in the console but is effectively meaningless in practice. Treat each exception as technical debt with a defined payoff date. A quarterly review of project-level policy overrides is a reasonable baseline for most organisations.

Consider using project labels or tags to mark exception projects. This makes it easier to audit exceptions programmatically and spot any that have outlived their justification.

Organisation Policy vs VPC Service Controls

These two controls are frequently mentioned together but solve fundamentally different security problems. They are complementary, and most mature GCP environments use both.

Use Organisation Policy to prevent misconfiguration. Use VPC Service Controls to limit blast radius if a credential is compromised. A project can have both enforced simultaneously, and many compliance frameworks recommend exactly that.