CIS_GCP_Foundation_4_0 — version 2.19

Source: presets/cis/CIS-GCP-Foundation-4.0.satz

Purpose

The CIS GCP Foundation 4.0 organization-policy set, managed constraints included.

Every constraint the benchmark asks for as an org policy, with the six superseded legacy twins declared OFF (spec { reset = true }) so that no organisation ends up with both forms of a constraint enforcing. Some policies have to be activated before they can be imported.

The benchmark: https://www.cisecurity.org/cis-gcp-foundation-4-0-policies/ Google's constraint catalogue: https://docs.cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints

Use it

params {
  use_cis_baseline = true

  // the pack's own defaults — copy only the lines you change
  cis_block_project_ssh_keys = false
  cis_require_shielded_vm = false
  cis_confidential_computing = false
  cis_cloud_sql_hardening = false
  cis_cmek_required = false
  cis_api_key_services = false
  cis_bucket_retention = false
  cis_access_approval = false
  cis_cloud_sql_iam_and_deletion_protection = false
  cis_sa_key_creation_rules = [ { enforce = "TRUE" } ]
  cis_api_key_services_dry_run = false
  cis_block_project_ssh_keys_dry_run = false
  cis_bucket_retention_dry_run = false
  cis_cloud_sql_hardening_dry_run = false
  cis_confidential_computing_dry_run = false
  cis_cloud_sql_iam_and_deletion_protection_dry_run = false
  cis_dns_logging = true
  cis_block_internet_ssh_rdp = true
  allowed_resource_locations = [ "in:eu-locations", "in:us-locations" ]
  allowed_policy_member_principal_sets = [
    "//cloudresourcemanager.googleapis.com/organizations/{customer_organization_id}",
  ]
  allowed_policy_member_subjects = [
    "serviceAccount:service-org-{customer_organization_id}@security-center-api.iam.gserviceaccount.com",
    "serviceAccount:service-org-{customer_organization_id}@gcp-sa-csc-hpsa.iam.gserviceaccount.com",
    "serviceAccount:service-org-{customer_organization_id}@gcp-sa-dspm-hpsa.iam.gserviceaccount.com",
    "serviceAccount:service-org-{customer_organization_id}@gcp-sa-ee-hpsa.iam.gserviceaccount.com",
    "serviceAccount:service-org-{customer_organization_id}@gcp-sa-ktd-hpsa.iam.gserviceaccount.com",
  ]
  allowed_protocol_forwarding_schemes = [ "INTERNAL" ]
  essential_contacts_allowed_domains = [ "@{customer_domain}" ]
}

use "presets/cis/CIS-GCP-Foundation-4.0.satz" when use_cis_baseline

use_cis_baseline is the gate: while it is falsy the pack contributes nothing — no resources, no params, no claims. It is declared by estate_map, and the estate's own binding wins.

Needs from outside the pack:

• customer_domain — declared by estate_core; use one of them alongside, or declare it in the estate.
• customer_organization_id — declared by estate_core; use one of them alongside, or declare it in the estate.

Params

Questions

What to ask before this pack is configured, and what changing the answer costs.

cis_block_project_ssh_keys — An estate that relies on project-wide keys for break-glass access loses it the moment this is enforced, and the managed constraint is still PREVIEW with no legacy form to fall back to. Per-instance keys and OS Login keep working.

cis_require_shielded_vm — Not every image supports Shielded VM: an organisation with custom or older images fails instance creation until they are rebuilt — and this is the one constraint with no dry-run, so it cannot be rehearsed before it bites.

cis_confidential_computing — Confidential VMs are limited to particular machine families and cost more; enforced organisation-wide this stops most ordinary workloads from starting.

cis_cloud_sql_hardening — Existing instances reached over a public IP lose connectivity the moment this is enforced; the private path has to exist first.

cis_api_key_services_dry_run — Google evaluates the rule and logs every action it would have blocked, blocking none of them, so the violation count is this organisation's own answer to whether enforcing it causes an outage. Turn this on INSTEAD of cis_api_key_services, not beside it. Nothing is enforced while it runs and the control reports as unmet, which is the truth; promote by switching this off and cis_api_key_services on.

cis_block_project_ssh_keys_dry_run — Google evaluates the rule and logs every action it would have blocked, blocking none of them, so the violation count is this organisation's own answer to whether enforcing it causes an outage. Turn this on INSTEAD of cis_block_project_ssh_keys, not beside it. Nothing is enforced while it runs and the control reports as unmet, which is the truth; promote by switching this off and cis_block_project_ssh_keys on.

cis_bucket_retention_dry_run — Google evaluates the rule and logs every action it would have blocked, blocking none of them, so the violation count is this organisation's own answer to whether enforcing it causes an outage. Turn this on INSTEAD of cis_bucket_retention, not beside it. Nothing is enforced while it runs and the control reports as unmet, which is the truth; promote by switching this off and cis_bucket_retention on.

cis_cloud_sql_hardening_dry_run — Google evaluates the rule and logs every action it would have blocked, blocking none of them, so the violation count is this organisation's own answer to whether enforcing it causes an outage. Turn this on INSTEAD of cis_cloud_sql_hardening, not beside it. Nothing is enforced while it runs and the control reports as unmet, which is the truth; promote by switching this off and cis_cloud_sql_hardening on.

cis_confidential_computing_dry_run — Google evaluates the rule and logs every action it would have blocked, blocking none of them, so the violation count is this organisation's own answer to whether enforcing it causes an outage. Turn this on INSTEAD of cis_confidential_computing, not beside it. Nothing is enforced while it runs and the control reports as unmet, which is the truth; promote by switching this off and cis_confidential_computing on.

cis_cloud_sql_iam_and_deletion_protection_dry_run — Google evaluates the rule and logs every action it would have blocked, blocking none of them, so the violation count is this organisation's own answer to whether enforcing it causes an outage. Turn this on INSTEAD of cis_cloud_sql_iam_and_deletion_protection, not beside it. Nothing is enforced while it runs and the control reports as unmet, which is the truth; promote by switching this off and cis_cloud_sql_iam_and_deletion_protection on.

cis_cmek_required — The most disruptive control in the set: every new resource of a listed service must be created with a CMEK, so the key rings, the keys and the grants have to exist first — and the pack cannot know which projects may supply keys.

cis_api_key_services — An API key that today calls anything stops working the moment this is enforced unless its targets are already narrowed. Set the allowed services first, then enforce.

cis_bucket_retention — It constrains EVERY bucket, not only the log sink's: once set, a bucket may carry a retention policy only if its duration is in the list, so buckets on other durations can no longer be updated.

cis_access_approval — Every support case that needs to look at the customer's content then waits for someone on the notification list to approve. Access Transparency (CIS 4.0 §2.14 / 5.0 §2.15) is a MANUAL prerequisite: an organisation administrator holding Access Transparency Admin (roles/axt.admin) switches it on in the Cloud console under IAM & Admin → Settings → Enable Access Transparency, before the apply that creates the Access Approval settings — there is no gcloud command, API or provider resource for it, it needs a Standard, Enhanced or Premium support plan, and the apply fails without it.

cis_block_internet_ssh_rdp — On by default, because an organisation that has not closed ports 22 and 3389 to the internet is one scan away from the finding it will be asked about. A hierarchical firewall policy on the organisation is read before every VPC rule: a session reaching an instance from a PUBLIC address on either port ends the moment the policy attaches. Internal administration is not touched — the pass list carries the three private blocks as well as Google's IAP range — so what breaks is a bastion with an external IP, which needs its range listed or its access moved to IAP. Every rule logs, which is what fills the firewall half of a SIEM. Answering no is a deviation and needs a reason an auditor will read.

cis_cloud_sql_iam_and_deletion_protection — Every Cloud SQL create and update in the organisation must then carry both settings; tooling that creates instances without them fails, and an existing instance that lacks one is refused its next update until that update adds it.

cis_dns_logging — On by default: DNS query logs are how a compromised host asking for its command-and-control domain becomes visible, and they are small beside flow logs — one entry per query, no sampling knob. What it enforces is only half the control: a DNS policy that exists must have logging on, because no org policy can require that a network HAS a policy at all. The other half is verified live — report-compliance names the networks without one. What it breaks: creating or updating a DNS policy with logging off is refused. Answering no is a deviation and needs a reason.

allowed_resource_locations — Data residency is the customer's decision, not the pack's. Narrowing later refuses creation outside the list and leaves what already exists elsewhere non-compliant; widening later is what an operator once did by hand, and the next apply undid it.

allowed_policy_member_principal_sets — The default is the customer's own organisation. A partner organisation whose identities need roles here has to be listed, or every grant to them is refused; one listed too many opens the estate to a directory the customer does not control.

allowed_policy_member_subjects — The default is Security Command Center's five organisation-level service agents, canonical and free to allow. A product whose service agent is not listed fails at the grant — Firebase Hosting, for one. Overriding REPLACES the list: keep the five when adding. A pack that needs a principal allowed contributes it itself; this answer is for the estate's own exceptions.

Notices

What to run once this pack is switched on. satz shows each notice when the pack goes on and until the estate binds its param true; every command that writes to the organisation refuses while one whose severity is error is open.

Contributes

Claims

What the controls ask (this project's paraphrase from the catalog — never the framework's own text):

• Cloud Asset Inventory enabled (cis-gcp 5.0 §2.14) — The Cloud Asset API is enabled so the organisation's resource inventory can be queried and its history kept.
• Cloud Audit Logging on all services (cis-gcp 4.0 §2.1, cis-gcp 5.0 §2.1) — Data Access audit logs (ADMIN_READ/DATA_READ/DATA_WRITE) enabled org-wide for all services.
• Compute instances without public IP addresses (cis-gcp 4.0 §4.9, cis-gcp 5.0 §4.9) — VMs are not reachable directly from the internet via external IPs.
• Corporate login credentials only (cis-gcp 4.0 §1.1, cis-gcp 5.0 §1.2) — IAM grants are restricted to identities from the organisation's own directory; consumer accounts cannot be granted roles.
• Default network does not exist (cis-gcp 4.0 §3.1, cis-gcp 5.0 §3.1) — New projects are created without the auto-mode default VPC and its permissive firewall rules.
• Essential Contacts configured for the organisation (cis-gcp 4.0 §1.16, cis-gcp 5.0 §1.17) — Organisation-level Essential Contacts are set so Google security, billing and legal notices reach a monitored address.
• IP forwarding not enabled on instances (cis-gcp 4.0 §4.6, cis-gcp 5.0 §4.6) — Instances may not forward packets for addresses other than their own.
• OS Login enabled (cis-gcp 4.0 §4.4, cis-gcp 5.0 §4.4) — VM SSH access goes through OS Login and IAM rather than project-wide or instance metadata keys.
• Only GCP-managed service account keys (cis-gcp 4.0 §1.4, cis-gcp 5.0 §1.5) — User-managed service account keys cannot be created or uploaded; only Google-managed keys exist.
• Organization policies configured for centralized constraints (cis-gcp 5.0 §1.1.4) — An organization-level policy baseline (resource locations, OS Login, external IPs, uniform bucket access, allowed member domains …) constrains every project centrally.
• Serial port access not enabled on VM instances (cis-gcp 4.0 §4.5, cis-gcp 5.0 §4.5) — Interactive serial console access is off, so a VM cannot be reached outside IAM-governed paths.
• Service accounts without admin privileges (cis-gcp 4.0 §1.5, cis-gcp 5.0 §1.6) — Default service accounts do not receive primitive or privileged roles automatically.
• Storage buckets not anonymously or publicly accessible (cis-gcp 4.0 §5.1, cis-gcp 5.0 §5.1) — Public access prevention is enforced so buckets cannot be exposed to allUsers/allAuthenticatedUsers.
• Uniform bucket-level access enabled (cis-gcp 4.0 §5.2, cis-gcp 5.0 §5.2) — Object ACLs are disabled; access is governed by IAM alone.
• VPC Flow Logs enabled on subnets (cis-gcp 4.0 §3.8, cis-gcp 5.0 §3.10) — Subnets record flow logs so network traffic is auditable.

Manual duties (a control stays partial until each is attested):

• appliances (cis-gcp 4.0 §4.6, cis-gcp 5.0 §4.6) — NAT gateways and network appliances legitimately need IP forwarding; grant an exception deliberately rather than relaxing the org policy.
• existing-vms (cis-gcp 4.0 §4.4, cis-gcp 5.0 §4.4) — Enforcing OS Login can cut existing SSH access patterns; verify before enabling on an org with running VMs.
• legacy-superseded (cis-gcp 5.0 §1.2) — The legacy iam.allowedPolicyMemberDomains is superseded, not forgotten — see the 4.0 claim for why running it would weaken rather than strengthen the control.
• legacy-superseded (cis-gcp 4.0 §1.1) — The legacy iam.allowedPolicyMemberDomains is superseded, not forgotten. Google states it cannot configure exceptions for specific principals, so its only remedy for granting a Google service agent is to DISABLE the constraint, grant, and re-enable. Running it therefore does not add protection — it converts every service activation into a window where domain-restricted sharing is switched off org-wide. The managed constraint enforces the same control continuously while naming its exceptions explicitly, which is why this baseline runs the managed constraint alone and, since v2.5, declares the legacy one reset instead of simply omitting it: an omitted constraint that is already set on the organisation goes on enforcing, unseen by the apply.
• review-allowlist (cis-gcp 4.0 §1.1, cis-gcp 5.0 §1.2) — Re-check allowed_policy_member_principal_sets / _subjects whenever a partner directory is added or a Google-managed service agent needs a grant.
• review-baseline (cis-gcp 5.0 §1.1.4) — The baseline is a decision, not a default — re-read it when the organisation adds a workload class the current constraints were not chosen for.

Not every resource this pack contributes is a witness:

• google_org_policy_policy.iam_allowedPolicyMemberDomains_superseded — declared OFF (spec { reset = true }): a superseded legacy twin, which proves nothing by design.
• google_org_policy_policy.compute_requireOsLogin_superseded — declared OFF (spec { reset = true }): a superseded legacy twin, which proves nothing by design.
• google_org_policy_policy.essentialcontacts_allowedContactDomains_superseded — declared OFF (spec { reset = true }): a superseded legacy twin, which proves nothing by design.
• google_org_policy_policy.iam_disableServiceAccountKeyCreation_superseded — declared OFF (spec { reset = true }): a superseded legacy twin, which proves nothing by design.
• google_org_policy_policy.iam_disableServiceAccountKeyUpload_superseded — declared OFF (spec { reset = true }): a superseded legacy twin, which proves nothing by design.
• google_org_policy_policy.compute_restrictProtocolForwardingCreationForTypes_superseded — declared OFF (spec { reset = true }): a superseded legacy twin, which proves nothing by design.

History

The whole library's history: the changelog in presets/CHANGELOG.md.

Notes

Six of the twenty-six policies are the legacy twins of a managed constraint, declared off at -superseded addresses. An estate coming from an earlier version of this pack holds them at their old addresses, so satz adopt --only google_org_policy_policy --execute --import moves them before the first apply; a plan that proposes to DESTROY one of them is the sign that step is still owed. satz plan/apply add the -replace such a twin needs (the API refuses rules and reset = true in one update).

The ten cis_* params here are the gates of presets/cis/ — one page each, each with the cost of switching it on. allowed_policy_member_subjects is where an external identity goes before any grant to it applies: Security Command Center's agents and Defender's scanning account among them.