s2_security_groups — version 1.2

Source: presets/security-group-models/s2-security-groups.satz

Purpose

The S2 security group model: S1's five admin groups plus a distinct NETWORK ADMINS group, and the org-level grants split accordingly. In S1 the network authority is folded into project-admins (compute.networkAdmin, compute.xpnAdmin — "Hybrid Connectivity administrators … Network administrators" in their description); S2 carves it out so a network team can own VPCs, Shared VPC, firewalls, DNS and connectivity without the project-admin power over everything else, and project-admins lose exactly those two network roles. Everything else is S1 unchanged.

Groups and grants in ONE file (typed sections beside the estate's own):

To adopt groups that already exist in the tenant: satz adopt --only google_cloud_identity_group --execute Memberships are NOT part of this pack: presets define groups, humans grant membership.

Required from the estate: customer_domain, svc_iac_account, infra_project_name

Use it

params {
  // the pack's own defaults — copy only the lines you change
  gcp_organization_admins_name = "gcp-organization-admins"
  gcp_project_admins_name = "gcp-project-admins"
  gcp_network_admins_name = "gcp-network-admins"
  gcp_security_admins_name = "gcp-security-admins"
  gcp_security_viewers_name = "gcp-security-viewers"
  gcp_billing_admins_name = "gcp-billing-admins"
}

use "presets/security-group-models/s2-security-groups.satz"

Needs from outside the pack:

• customer_domain — declared by estate_core; use one of them alongside, or declare it in the estate.
• infra_project_name — declared by estate_core; use one of them alongside, or declare it in the estate.
• svc_iac_account — 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.

gcp_organization_admins_name — The address is the group's identity: renaming it later means a new group, every member moved by hand and every role re-granted. This group holds the organisation's highest roles.

gcp_project_admins_name — The address is the group's identity: renaming it later means a new group, every member moved by hand and every role re-granted.

gcp_network_admins_name — The address is the group's identity: renaming it later means a new group, every member moved by hand and every role re-granted. S2's reason to exist: the network authority carved out of project admins.

gcp_security_admins_name — The address is the group's identity: renaming it later means a new group, every member moved by hand and every role re-granted.

gcp_security_viewers_name — The address is the group's identity: renaming it later means a new group, every member moved by hand and every role re-granted.

gcp_billing_admins_name — The address is the group's identity: renaming it later means a new group, every member moved by hand and every role re-granted.

Contributes

Claims

None — this pack proves no control by itself.

History

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

Notes

S1 vs S2 — who holds what

Why the split: Shared VPC host projects, firewall policies and hybrid connectivity are org-wide blast radius; S1 hands them to every project admin. S2 gives them to one team without owner or any IAM-admin role — a network admin can wire a project but cannot grant anyone anything. compute.securityAdmin is included because firewall policies (hierarchical rules) need it and compute.networkAdmin alone cannot edit them; dns.admin because private zones and peering are network work in practice.

Roles and teams — who sits where

Which model — a team-shape decision

S1 fits when one platform team does both the project administration and the networking — typically up to the low tens of projects, one or two hub VPCs, and the same two or three engineers touching both. The network roles ride along in project-admins because the people are the same; a separate group would only add membership overhead.

S2 fits as soon as network and project administration are different people — a dedicated network/connectivity team, Shared VPC with many service projects, hierarchical firewall policies, hybrid connectivity to an on-prem estate, or a regulator who asks for separation of duties. The network team gets org-wide reach over connectivity and nothing else; project admins keep their projects but can no longer re-wire the network. Choose S2 on day 0 when that team split is already visible on the org chart: moving from S1 to S2 later is a pack swap plus re-adopting the new group, but every project admin silently loses two roles at that apply — announce it.

Both are typed packs for a top-level use, one line each.

Memberships are never in a pack: adopt the groups (satz adopt --only google_cloud_identity_group --execute), then humans add members in the console or with gcloud.