TopolearnIAM decides who may act; org policies decide what configurations are allowed at all, for everyone.
The Organization Policy Service sets constraints on resource configuration across the hierarchy. Where IAM says "Alice may create buckets", org policy says "no bucket anywhere may be public" or "resources may only be created in EU locations", even for Owners.
Constraint types:
- Boolean: on or off, e.g.
iam.disableServiceAccountKeyCreation,storage.publicAccessPrevention,compute.requireOsLogin,sql.restrictPublicIp. - List: allowed or denied values, e.g.
gcp.resourceLocations(with value groups likein:eu-locations),compute.vmExternalIpAccess,iam.allowedPolicyMemberDomains(domain-restricted sharing). - Custom constraints: your own rules as CEL conditions on resource fields for supported services, e.g. "GKE clusters must enable Workload Identity". Google's newer managed constraints are built on the same engine.
Policies are set on org, folder or project and inherited. A child can replace or, for list constraints, merge with the parent (inheritFromParent). Tags let you apply conditional rules ("enforce unless tagged env=sandbox").
Org policies apply on create or update; existing non-compliant resources are not changed. Roll out safely with a dry-run spec, which logs would-be violations without enforcing, then enforce. Managing policies needs roles/orgpolicy.policyAdmin, usually granted only at the org level. Newer organizations get a set of secure-by-default constraints enforced automatically.
Example
cat > locations.yaml <<'EOF'
name: folders/123456789012/policies/gcp.resourceLocations
spec:
rules:
- values:
allowedValues:
- in:eu-locations
EOF
gcloud org-policies set-policy locations.yaml
cat > no-keys.yaml <<'EOF'
name: organizations/555555555555/policies/iam.disableServiceAccountKeyCreation
spec:
rules:
- enforce: true
EOF
gcloud org-policies set-policy no-keys.yaml
# What actually applies to a project after inheritance?
gcloud org-policies describe gcp.resourceLocations --project=shop-dev-4821 --effectiveRemember
- Org policy constrains configuration for everyone; IAM grants actions to someone
- Boolean, list and custom (CEL) constraints, inherited down the tree
- Only new creates/updates are checked; use dry run before enforcing
Watch out for
- Enforcing a location or domain restriction org-wide without dry run and breaking deployments that depend on global resources.