Policy as Code

Policy as code is how an organization enforces rules — "buckets must have CMEK," "no public IPs," "only approved regions" — automatically instead of in a wiki nobody reads. The previous topics gated correctness and security on the way into Terraform. This one gates the rules the whole organization cannot break, and on Google Cloud that takes three layers, not two.

Sentinel and OPA gate the Terraform path at plan time. GCP Org Policy enforces at the API itself, at apply and at runtime, no matter how the change arrives. The third layer is the GCP-native one, and it closes a hole the first two structurally cannot: anything that leaves the Terraform path entirely.

Sentinel

Sentinel is HashiCorp's policy language, enforced by HCP Terraform between plan and apply. It reads the plan and the run's configuration and can hard-fail the run, soft-fail it (block unless overridden), or merely advise. The catch is scope: Sentinel gates only runs that execute on HCP Terraform, and it is a paid-tier feature. A terraform apply from a laptop or a plain CI runner never reaches it.

So Sentinel is the right plan-time layer when your runs already go through HCP Terraform and you want policy woven into the run pipeline. It is the wrong layer if some of your applies happen anywhere else, because those simply skip it.

OPA and conftest

Open Policy Agent uses Rego, and the open-source path is to export the plan as JSON and evaluate policies against it. You run terraform show -json plan.out to get the resolved plan, then conftest test over it in CI on any runner — no HCP Terraform, no paid tier. That gates the Terraform path wherever your pipeline runs.

The detail that matters is what you evaluate. OPA policies must run against the plan JSON, not the raw HCL, because computed values and module expansion only exist in the resolved plan. A policy written against the HCL sees module.ingest as an opaque call; the same policy against the plan JSON sees every resource it expands into, with its computed attributes filled in. But like Sentinel, OPA still only sees the Terraform path.

# resolve the plan, then evaluate Rego against the JSON — not the HCL
terraform plan -out=plan.out
terraform show -json plan.out > plan.json
conftest test plan.json

The two commands turn a binary plan into the JSON document Rego reasons over. Skip the export and write policy against .tf files directly, and the policy is blind to everything Terraform computes — which is most of what you want to check.

GCP Org Policy

GCP Org Policy is the GCP-native layer with no Terraform-tool analog. A google_org_policy_policy resource sets a constraint — storage.publicAccessPrevention, compute.vmExternalIpAccess, gcp.resourceLocations — at an organization, folder, or project node. The constraint is enforced by the API itself: a request that violates it is rejected server-side. That holds whether the change arrives from Terraform, from gcloud, from the Cloud Console, or from another pipeline entirely. It cannot be bypassed by leaving Terraform, because it does not live in Terraform.

The example sets two of the org's non-negotiables at the org node. Once these are enforced, no path — not a 2am gcloud command, not a Console click — can create a publicly readable bucket or attach an external IP, because the API refuses the request before the resource exists.

resource "google_org_policy_policy" "no_public_buckets" {
  name   = "organizations/123456789/policies/storage.publicAccessPrevention"
  parent = "organizations/123456789"

  spec {
    rules {
      enforce = "TRUE"     # API rejects any public bucket, any path
    }
  }
}

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

  spec {
    rules {
      deny_all = "TRUE"    # no VM gets a public IP, no matter who asks
    }
  }
}

Neither rule references Terraform. They configure GCP's own enforcement engine, so they apply to every actor against the API — which is exactly the property the plan-time layers lack.

Plan-Time vs API-Time

Sentinel and OPA evaluate a proposed plan and stop a bad apply before it runs. The feedback is fast and lands in the pull request — "your plan violates policy X" — so a developer fixes it before merge. Org Policy evaluates the actual API call and rejects it server-side. There is no bypass, but the failure shows up at apply as an API error, not in the PR. Neither timing is strictly better; they fail at different moments and catch different things.

That is why you want both. The plan-time layer gives early, legible feedback on the Terraform path. The API-time layer gives an unbypassable backstop on every path. Pick one and you either lose fast feedback or lose the guarantee that a non-Terraform change cannot violate the rule.

How the Three Complement

OPA or Sentinel give developers a fast "your plan violates policy" in CI before anything reaches GCP — cheap to run, easy to read, and it blocks the merge. Org Policy guarantees that even a panicked engineer running gcloud at 2am cannot create a public bucket, because the API itself refuses. The same rule is enforced at the cheap early gate and the expensive unbypassable one.

That is defense in depth applied to policy. The plan-time layer optimizes for developer experience; the API-time layer optimizes for the guarantee. Encode the org's non-negotiables as Org Policy so nothing can violate them, and mirror them in OPA or Sentinel so a violation is caught in PR rather than as an opaque apply-time error. Both layers, the same rules, two different moments.