Google Cloud — Organization Policies

Organization Policies allow centralized guardrails across your entire GCP resource hierarchy. They define constraints on service usage, resource configurations, and security settings at the organization, folder, or project level. Understanding policy inheritance and how to use custom constraints is key to enforcing governance without breaking workflows.

Why Organization Policies Matter in Production

Organization policies in Google Cloud are the first line of defense against misconfiguration at scale. They enforce guardrails across all projects in an organization, hierarchy node, or folder. Without them, you rely on individual project owners to follow best practices—a recipe for drift. In production, a single project with public bucket access or unconstrained service account key creation can lead to data exfiltration. Organization policies are evaluated at resource creation time and periodically, so they block non-compliant actions before they happen. They are not retroactive; existing resources are not automatically fixed. This means you must combine policies with continuous compliance scanning. The policy engine uses a constraint model: each constraint defines a condition (e.g., constraints/iam.disableServiceAccountKeyCreation) and an enforcement action (allow, deny, or audit). You can also use custom constraints with CEL (Common Expression Language) for fine-grained control. In production, start with a baseline of recommended constraints from Google's security blueprint, then layer custom policies for your specific compliance needs.

gcloud organizations list --format='value(ID)' | head -1 | xargs -I {} gcloud resource-manager org-policies list --organization={}

Hierarchy and Policy Inheritance

Policies in Google Cloud follow a hierarchical inheritance model: organization -> folders -> projects. A policy set at the organization level applies to all descendants unless overridden. Overrides are allowed only if the parent policy has inheritFromParent set to false and the child explicitly sets a different policy. This is powerful but dangerous: a folder-level override can weaken security for a subset of projects. In production, you should minimize overrides. Use folders to group environments (e.g., dev, staging, prod) and apply stricter policies on prod folders. For example, you might allow service account key creation in dev but deny it in prod. To enforce this, set the organization policy to deny by default, then create a folder-level policy for dev that allows it. But be careful: if someone creates a new folder under prod, it inherits the prod policy automatically. Audit your hierarchy regularly. Use gcloud resource-manager org-policies describe to check effective policy on any resource. Remember that policy evaluation is AND-based: if any ancestor denies, the action is denied. So a deny at the org level cannot be overridden by a folder allow—only a parent allow can be overridden by a child deny.

gcloud resource-manager org-policies describe constraints/compute.requireOsLogin --project=my-project --effective

Built-in Constraints: The Security Baseline

Google Cloud provides over 100 built-in constraints covering IAM, Compute, Storage, and more. These are the quickest way to enforce security best practices. Critical ones include: iam.disableServiceAccountKeyCreation (prevents creation of user-managed keys), compute.requireOsLogin (enforces OS Login for SSH), storage.publicAccessPrevention (blocks public buckets), iam.disableCrossProjectServiceAccountUsage (prevents service account impersonation across projects), and sql.restrictPublicIp (forces Cloud SQL to use private IP). In production, enable these on the organization root immediately. But be aware of side effects: disabling service account key creation breaks legacy applications that rely on keys. You must migrate to workload identity federation or OAuth2. Similarly, compute.requireOsLogin breaks existing SSH key-based access. Plan a migration window. Use the gcloud resource-manager org-policies list command to see all available constraints. For each constraint, understand the listPolicy vs booleanPolicy types. List policies allow you to specify allowed/denied values (e.g., allowed regions), while boolean policies are simple on/off. Start with boolean policies for security controls, then use list policies for compliance (e.g., allowed locations).

gcloud resource-manager org-policies set-policy policy.yaml --organization=123456789012
# policy.yaml content:
# constraint: constraints/storage.publicAccessPrevention
# booleanPolicy:
#   enforced: true

Custom Constraints with CEL

When built-in constraints aren't enough, create custom constraints using Common Expression Language (CEL). Custom constraints allow you to enforce rules on resource properties that aren't covered by built-in ones. For example, you can require that all Compute Engine instances have a specific label, or that Cloud SQL instances have a minimum disk size. Custom constraints are defined as YAML files and applied via gcloud org-policies set-custom-constraint. They consist of a resource type, condition (CEL expression), and action (allow or deny). The CEL expression can reference resource fields, e.g., resource.labels.environment == 'prod'. In production, use custom constraints for compliance requirements like data residency (e.g., enforce that resources are in specific regions) or tagging standards. However, custom constraints have limitations: they are evaluated only at resource creation/update, not periodically. Also, CEL has a limited set of functions; you cannot do complex joins or external lookups. Test custom constraints thoroughly in a non-production environment. Monitor Cloud Audit Logs for constraint violations. Remember that custom constraints are organization-level resources; you cannot scope them to folders directly, but you can attach them via organization policy at any level.

name: organizations/123456789012/customConstraints/custom.requireEnvLabel
resourceTypes:
- compute.googleapis.com/Instance
methodTypes:
- CREATE
- UPDATE
condition: "resource.labels.environment == 'prod' || resource.labels.environment == 'dev'"
actionType: DENY
condition: "!resource.labels.all(f, f.key.startsWith('env'))"
displayName: Require environment label
description: All instances must have a label starting with 'env'

Policy Troubleshooting and Audit Logging

When a policy blocks an action, the error message often says 'Access Denied by Organization Policy' but doesn't specify which constraint. To diagnose, check Cloud Audit Logs for orgpolicy.constraint violations. Use the Logs Explorer with query: protoPayload.serviceName="orgpolicy.googleapis.com". Each violation includes the constraint name and the resource. Also, use gcloud org-policies describe --effective to see the effective policy on a resource. If you're unsure why something is blocked, simulate the policy using the gcloud org-policies simulate command (beta). This is especially useful for custom constraints. In production, set up log-based alerts for policy violations. For example, alert when a deny occurs on a prod folder. Also, monitor the orgpolicy.googleapis.com/Deny metric in Cloud Monitoring. Remember that policy evaluation can be complex due to inheritance; use the --effective flag to see the final result. If you have multiple constraints, they are evaluated independently; a single deny blocks the action. There is no ordering. For troubleshooting, also check if the resource type is supported by the constraint; some constraints only apply to certain APIs.

gcloud org-policies simulate --organization=123456789012 --constraint=constraints/compute.requireOsLogin --resource=projects/my-project --action=create

Managing Policies as Code with Terraform

Manual policy management via gcloud is error-prone at scale. Use Terraform's google_org_policy resource to manage policies as code. This enables version control, code review, and CI/CD. The resource supports both boolean and list policies. For custom constraints, use google_org_policy_custom_constraint. In production, store policies in a dedicated repository and apply them via a pipeline with approval gates. Use Terraform workspaces or folders to separate environments. Be careful with policy drift: if someone manually changes a policy via the console, Terraform will revert it on the next apply. To avoid this, use terraform plan and review changes. Also, note that Terraform's google_org_policy resource has a dry_run option for testing. For list policies, use allow and deny blocks with values. For boolean policies, use enforced. Remember that Terraform state can become large if you manage many policies; consider using google_org_policy with spec instead of the deprecated google_organization_policy. Always pin the provider version.

resource "google_org_policy" "require_os_login" {
  org_id = var.org_id
  constraint = "constraints/compute.requireOsLogin"
  boolean_policy {
    enforced = true
  }
}

resource "google_org_policy_custom_constraint" "require_env_label" {
  org_id = var.org_id
  name = "custom.requireEnvLabel"
  display_name = "Require environment label"
  description = "All instances must have label starting with 'env'"
  condition = "resource.labels.all(f, f.key.startsWith('env'))"
  action_type = "DENY"
  method_types = ["CREATE", "UPDATE"]
  resource_types = ["compute.googleapis.com/Instance"]
}

Scoped Policies: Folders vs Projects

While organization-level policies are ideal for baseline security, you often need different policies for different environments. Use folders to scope policies. For example, apply a strict policy to the 'prod' folder and a relaxed one to 'dev'. But remember inheritance: if the org policy denies something, a folder allow won't work. So design your hierarchy with the most restrictive policies at the top. For project-level policies, use them sparingly; they are hard to manage at scale. Instead, use folders for logical groupings. In production, create folders for each environment (dev, staging, prod) and possibly for each business unit. Apply policies at the folder level that are specific to that environment. For example, prod might require VPC Service Controls, while dev does not. Use gcloud resource-manager folders list to see your hierarchy. Also, consider using google_folder_organization_policy in Terraform. Be aware that moving a project between folders can change its effective policy; plan project moves carefully. Audit folder-level policies regularly to ensure they haven't drifted.

gcloud resource-manager org-policies set-policy folder-policy.yaml --folder=123456789012
# folder-policy.yaml:
# constraint: constraints/iam.disableServiceAccountKeyCreation
# booleanPolicy:
#   enforced: true

Monitoring and Compliance Automation

Organization policies are not a set-and-forget solution. You need continuous monitoring to detect violations and drift. Use Cloud Asset Inventory to export all resources and their effective policies. Set up automated compliance checks using Cloud Functions or Cloud Run that run on a schedule. For example, a function that checks if any project has a public bucket despite the policy (policy might not be retroactive). Also, use Security Command Center (SCC) to get findings for policy violations. SCC integrates with organization policies and provides a dashboard. In production, create a remediation pipeline: when a violation is detected, automatically create a ticket or trigger a Cloud Function to fix it (e.g., remove public access). But be careful with auto-remediation; it can cause cascading failures. Start with notification-only. Use Cloud Logging metrics to track policy denial rates. Set up alerts for spikes. Also, regularly review policy effectiveness: are there many denials? That might indicate a policy is too restrictive or users need training. Use the gcloud org-policies list command to see all policies and their enforcement state.

from google.cloud import asset_v1
from google.cloud import storage

client = asset_v1.AssetServiceClient()
scope = "organizations/123456789012"

# List all buckets
storage_client = storage.Client()
buckets = storage_client.list_buckets()
for bucket in buckets:
    iam = bucket.get_iam_policy()
    for binding in iam.bindings:
        if 'allUsers' in binding.members or 'allAuthenticatedUsers' in binding.members:
            print(f"Public bucket: {bucket.name}")

Common Pitfalls and Failure Modes

Even with organization policies, things go wrong. Common pitfalls include: (1) Overriding a deny with an allow at a lower level—this doesn't work because deny is AND-based. (2) Forgetting that policies only apply to new resources, leading to a false sense of security. (3) Applying a policy that breaks existing automation, like disabling service account keys when CI/CD uses them. (4) Using custom constraints with incorrect CEL syntax, causing the constraint to be silently ignored. (5) Not testing policies in a non-production folder first. (6) Assuming that policy evaluation is fast; it can take up to 30 seconds to propagate. (7) Not monitoring policy violations, so you don't know when something is blocked. In production, always have a rollback plan. Use Terraform to manage policies so you can revert quickly. Also, document each policy and its rationale. Train your team on what policies exist and why. Finally, remember that organization policies are just one layer; combine with IAM, VPC Service Controls, and Data Loss Prevention for defense in depth.

gcloud resource-manager org-policies delete constraints/compute.requireOsLogin --organization=123456789012

Advanced: Policy Dry Run and Gradual Rollout

Google Cloud supports a dry run mode for organization policies (currently in preview). When enabled, the policy is evaluated but not enforced. Violations are logged but not blocked. This is invaluable for testing new policies in production without breaking things. To use dry run, set dryRunSpec in the policy instead of spec. You can then monitor logs for violations. Once you're confident, switch to enforcement. For gradual rollout, apply the policy to a subset of projects using folder scoping. For example, first apply to a 'test' folder, then 'staging', then 'prod' with a delay. Use Terraform's google_org_policy with dry_run = true. Also, use Cloud Monitoring to track violation rates. If violations are low, proceed to enforcement. If high, investigate and adjust. This approach minimizes risk. In production, always have a dry run phase for any new policy, especially custom constraints. Document the rollout plan and have a rollback procedure. Remember that dry run policies still count toward policy limits.

resource "google_org_policy" "dry_run_require_os_login" {
  org_id = var.org_id
  constraint = "constraints/compute.requireOsLogin"
  dry_run_spec {
    enforce = true
  }
}

Integrating with VPC Service Controls

Organization policies and VPC Service Controls (VPC SC) complement each other. While org policies control resource configuration, VPC SC controls data exfiltration by defining perimeters around resources. For example, you can use an org policy to enforce that all GCS buckets are private, and VPC SC to prevent data from being copied outside your perimeter. In production, combine them for defense in depth. However, be aware of interactions: VPC SC can override org policies in some cases? No, they are independent. But if VPC SC denies access, the action fails regardless of org policy. Also, VPC SC has its own set of constraints (e.g., vpcAccess.connector). Use org policies to enforce VPC SC requirements, like requiring VPC connectors for serverless. For example, a custom constraint can enforce that Cloud Functions have a VPC connector. This ensures that functions are inside the perimeter. Test both together in a non-production environment. Monitor both org policy violations and VPC SC violations separately.

constraint: constraints/compute.requireVpcConnector
listPolicy:
  allow:
    all: true

Policy Lifecycle and Governance

Organization policies need a lifecycle: create, test, deploy, monitor, update, retire. Establish a governance process. Use a policy committee to review new constraints. Store policies in a Git repository with a clear naming convention. Use pull requests for changes. Require approval from security team for any policy that denies actions. For updates, use Terraform plan to show impact. Monitor policy violations and review them quarterly. Retire policies that are no longer needed. Also, keep track of policy limits: maximum 2000 constraints per organization, 100 custom constraints. In production, automate policy compliance reporting. Use Cloud Asset Inventory to export effective policies and compare with desired state. Generate a weekly report. Finally, educate your team: create a wiki page explaining each policy and its rationale. This reduces friction and helps developers understand why their actions are blocked.

gcloud asset search-all-resources --scope=organizations/123456789012 --asset-types=orgpolicy.googleapis.com/Policy --format=json > policies.json