Appendix C

Organization Policy Baseline

Scope. The manifest: every organization policy constraint this book applies, with its type, value, scope, and the section that argues for it. Grouped by control domain. Prerequisites. §2.30 for organization policy mechanics, §2.31 for inheritance, Chapter 31 for the argument behind every value here. Verified against. Google Cloud console and API surface as of 2026-09, Cloud SDK 583.0.0; every constraint ID verified against the organization policy constraint reference; see sources at end.

Chapter 31 owns the argument; this appendix owns the artifact. Why a constraint is set, what it breaks, which exceptions are legitimate, and what order to roll out in are all Chapter 31's, and none of it is repeated here. What follows is the list, cut by control domain rather than by rollout concern, so that a constraint met in a policy dump can be looked up by what it governs.

Seventy-five constraints, each appearing exactly once. Type is Boolean, List, or Managed: managed constraints carry no boolean/list label and take enforce with a parameter map rather than a value list. Scope is the resource the baseline applies it at. Constraint IDs are given in the constraints/-prefixed form; gcloud org-policies takes the bare ID as its positional argument.

Two mechanical facts govern everything below. gcloud org-policies has no allow or deny subcommand — every write goes through set-policy and a file. And for organizations created on or after 2024-05-03, seven constraints are already enforced; §31.1 lists them, and some organizations created between February and April 2024 have them too, so check rather than assume:

gcloud org-policies list --organization=123456789012
gcloud org-policies describe compute.requireOsLogin \
  --organization=123456789012 --effective

The complete Terraform manifest is code/tf/org-policy-baseline/main.tf, which applies the 48 boolean and managed constraints through one for_each and declares the list constraints individually, because with a list constraint the value is the decision.

C.1 Identity Controls §

Who may appear in an IAM policy, and who may be exempted from being logged. The managed form, constraints/iam.managed.allowedPolicyMembers, is parameterized with allowedMemberSubjects and allowedPrincipalSets; the legacy form carries allowed values only. Neither grants your own organization by default — see §31.5 for what that costs if the value is set without it.

C.2 Network Controls §

VPC topology, address assignment, and traffic visibility. Constraints whose subject is reachability by an arbitrary internet party are in C.7 instead, which is why constraints/sql.restrictAuthorizedNetworks is here and constraints/sql.restrictPublicIp is not.

C.3 Compute Controls §

Instance and node hardening: login path, boot integrity, serial console, and image provenance. constraints/compute.requireOsLogin, constraints/compute.requireShieldedVm, and constraints/compute.disableSerialPortAccess are not applied automatically at any organization age and belong in every baseline (§31.1).

C.4 Storage Controls §

Cloud Storage bucket-level controls other than public reachability, which is C.7. Two rows are placed here for reasons worth stating, because both look as though they belong elsewhere.

constraints/gcp.detailedAuditLoggingMode reads like a general audit-logging control and is Cloud Storage-specific; §31.10 warns against setting it in a logging baseline and expecting estate-wide effect. It is applied at the organization but takes effect on one service only.

constraints/gcp.disableCloudLogging is the one row in this appendix whose correct value is not to enforce it. Enforcing it turns Cloud Logging off for the resources below it, which is why §17.10 treats a non-default value as a finding rather than a control. It is listed so that its presence in a policy dump is recognized immediately.

C.5 Encryption Controls §

Key material, key provenance, destruction delay, and transport security. constraints/gcp.restrictNonCmekServices takes service names as values and is therefore rolled out service by service rather than in one step (§31.9).

C.6 Region Controls §

Where resources may exist and which Google surfaces they may reach — the estate boundary. The API constraints sit here rather than in a section of their own because they answer the same question as a location constraint: what is inside the estate. constraints/gcp.resourceLocations is the one baseline row applied at a folder rather than the organization, unless the whole estate is single-jurisdiction (§31.2).

C.7 Public Access Controls §

Reachability by an arbitrary internet party, across storage, database, serverless, and load balancing. These are the constraints whose exception, when one is genuinely needed, belongs at a folder holding only public assets (§31.7).

C.8 Service Account Controls §

Service account existence, keys, credential lifetime, and the build identities that default to one. The two key constraints belong to the automatic set described in §31.1; constraints/iam.serviceAccountKeyExpiryHours is scoped to a folder here because it exists to bound an exception rather than to state the rule (§31.4).

The lift §

One boolean constraint, as a set-policy document and as HCL. Every other row differs only in the constraint name and the rule body — enforce: true for boolean and managed, values with allowedValues or deniedValues for list.

name: organizations/123456789012/policies/compute.requireOsLogin
spec:
  rules:
    - enforce: true

resource "google_org_policy_policy" "require_os_login" {
  name   = "organizations/123456789012/policies/compute.requireOsLogin"
  parent = "organizations/123456789012"

  spec {
    rules {
      enforce = "TRUE"
    }
  }
}

Note that enforce, allow_all, and deny_all are the strings "TRUE" and "FALSE" in the provider, while inherit_from_parent and reset are real booleans, and that the resource name carries the constraint without the constraints/ prefix.

Sources §

• https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints (last validated 2026-09-04)
• https://cloud.google.com/resource-manager/docs/organization-policy/restricting-domains (last validated 2026-09-04)