Goal: land in a compliant posture on day one instead of remediating later.
Order matters: set org policies BEFORE the first terraform apply. Policies are guardrails, not retroactive fixers; resources created before the policy stay until you fix them.
Policies to consider at org or folder level:
- iam.allowServiceAccountKeyCreation: deny key creation org-wide if your posture is WIF/impersonation only. This breaks any automation that mints keys, so migrate that automation first.
- compute.requireOsLogin or VM external IP constraints: control SSH and public exposure posture.
- sql.restrictPublicIp: force Cloud SQL onto private IP from the start.
- constraints/compute.vmExternalIpAccess: deny external IPs where workloads should be private.
- storage uniform bucket-level access enforcement where applicable.
How to set:
```
gcloud resource-manager org-policies enable-enforce --organization [ORG-ID] [CONSTRAINT]
```
(list constraints with `gcloud resource-manager org-policies list --organization [ORG-ID]`)
Traps:
- Enforcing key-creation denial while your CI still uses keys breaks deploys instantly. Sequence: migrate auth, then enforce.
- Folder-level policies inherit; test at a sandbox folder before org-wide enforcement.
- Terraform google_organization_policy resources exist; manage policies in the same IaC repo so the guardrails are versioned too.
- Some constraints need the Org Policy API enabled and specific permissions (orgpolicy.policyAdmin).
Verify: attempt a violating create (e.g. mint a key) and confirm the policy denies it, then run the real apply and confirm zero violations in the policy analyzer.