Org Policies as Code

Org policies are the other half of GCP governance, and they answer a different question than IAM. IAM controls who can act; an org policy controls what can be created at all, regardless of who is asking. It is a guardrail that constrains the shape of resources across the hierarchy — "no VM in this org may have an external IP" — rather than a grant to a principal.

google_org_policy_policy applies a constraint like "no external IPs," "only these regions," or "OS Login required" at the org, a folder, or a project. Like IAM, it inherits down the tree: a constraint set on hatch.io binds every folder and project beneath it. The key property is that IAM cannot override it — a user with full roles/owner still cannot create what a constraint forbids. That is the entire point.

Orthogonal to IAM

IAM is the who: this group may create VMs. An org policy is the what: no VM in this org may have an external IP, even for someone with permission to create VMs. The two are orthogonal, and a user with complete IAM access still cannot violate an org policy. That is what makes org policies a real guardrail — they are the controls the project owner cannot click past, because no amount of IAM grants what a constraint denies.

This is the mental model to fix first, because the instinct from IAM is to "give someone permission" to do the blocked thing. There is no such permission. The only way past a constraint is to change the policy at a node where you are allowed to, which is itself an audited Terraform change — not a runtime grant.

The Resource and Constraints

google_org_policy_policy targets a node — organizations/123456789012, a folder, or a project — and sets a named constraint. The common ones disable external IPs (compute.vmExternalIpAccess), restrict resource locations (gcp.resourceLocations), and require OS Login (compute.requireOsLogin). The configuration below denies external IPs across the whole org, so a public IP can never be attached to a VM anywhere under hatch.io.

resource "google_org_policy_policy" "no_external_ip" {
  name   = "organizations/123456789012/policies/compute.vmExternalIpAccess"
  parent = "organizations/123456789012"

  spec {
    rules {
      deny_all = "TRUE"   # list constraint: empty allow-list, inherited by every project
    }
  }
}

Boolean vs List Constraints

Constraints come in two shapes. Boolean constraints are on/off — require OS Login is either enforced or it is not. List constraints allow or deny a set of values — allow only us-central1 and us-east1 as regions, or deny service-account key creation. The rules {} block expresses the allow/deny lists and the enforcement, and the difference matters when you write one: a boolean constraint uses enforce, a list constraint uses allow_all, deny_all, or explicit values.

A list constraint is where the sharpest self-inflicted outage lives. Write a gcp.resourceLocations allow-list of regional values and forget that Cloud Storage and BigQuery often use multi-regions like US, and bucket and dataset creation breaks across the org — the multi-region value is not in your allow-list, so it is denied. Test list constraints before they reach the org node.

Inheritance and Override

A policy set at hatch.io applies to all of platform/, apps/, and data/. Depending on the constraint's inheritance behavior, a child node can be allowed to override or merge — so the pattern is to set the strict default high and relax it deliberately where a project genuinely needs the exception. Deny external IPs at the org, then, in the one project that hosts a bastion, set a project-level policy that allows the bastion's IP. You design the exception at the node that needs it instead of weakening the org-wide default.

Guardrails That Constrain Creation

These are the controls that stop a public IP from ever being attached in hatch-app-prod, or stop a resource landing outside approved regions, before the risky resource exists. That is prevention, not detection — the difference between a constraint that refuses the terraform apply and a scanner that files a ticket after the fact. A guardrail that blocks creation closes the window in which the misconfiguration exists at all.

Org policies are not a substitute for IAM least-privilege; they are the complement. IAM is still the layer that decides who may create a VM at all, and an org policy decides what that VM may look like. Skip either and you leave a gap the other was meant to cover. The closing topic of the chapter turns from access to the metadata that classifies resources — labels, tags, and network tags.