Description of Documentation Need
Stage 2 governs environment firewalling via a hierarchical firewall policy associated to the Networking folder (module.firewall-policy-default, 2-networking-a-fedramp-high/main.tf:44-52, called with parent_id = module.folder.id and no region, dispatching to modules/net-firewall-policy/hierarchical.tf). The PostgreSQL blueprint instead creates a classic, network-scoped google_compute_firewall resource (main.tf:36) directly in network_project_id. Both are valid GCP constructs and coexist without conflict (hierarchical policies evaluate before classic VPC rules), but the blueprint's rule is invisible to anyone auditing the environment through its firewall policy (gcloud compute firewall-policies rules list does not show it) — it lives in a separate enforcement layer from the one Stage 2 establishes, and nothing in either README explains the split.
Target Audience
Security auditors reviewing the environment's firewall posture; operators reasoning about why a blueprint rule doesn't appear in the folder policy.
Proposed Location
A note in blueprints/il5/postgresql/README.md and/or the Stage 2 README.
Content Outline / Draft
- State that FRH/IL5 blueprints (currently) use classic per-network rules as a simpler, blueprint-local mechanism.
- Explain the coexistence and evaluation order (hierarchical → global/regional network policies → classic VPC rules).
- Note where to look when auditing (
firewall-policies rules list vs. firewall-rules list).
- Alternative to documenting: migrate the blueprint to emit a
google_compute_firewall_policy_rule against Stage 2's existing hierarchical policy — happy to discuss which direction maintainers prefer.
Compliance Context (if applicable)
Auditability/governance-transparency gap rather than a control failure; relevant to firewall-review procedures under FRH/IL4/IL5 (e.g., CM-6/SC-7 evidence gathering). Verified at 3728fc98: both networking variants govern via the same hierarchical firewall-policy-default module (2-networking-a-fedramp-high/main.tf:44 and 2-networking-b-il5-ngfw/main.tf:43), so the split applies regardless of regime; the postgresql blueprint ships in both the FRH and IL5 trees.
Description of Documentation Need
Stage 2 governs environment firewalling via a hierarchical firewall policy associated to the Networking folder (
module.firewall-policy-default,2-networking-a-fedramp-high/main.tf:44-52, called withparent_id = module.folder.idand noregion, dispatching tomodules/net-firewall-policy/hierarchical.tf). The PostgreSQL blueprint instead creates a classic, network-scopedgoogle_compute_firewallresource (main.tf:36) directly innetwork_project_id. Both are valid GCP constructs and coexist without conflict (hierarchical policies evaluate before classic VPC rules), but the blueprint's rule is invisible to anyone auditing the environment through its firewall policy (gcloud compute firewall-policies rules listdoes not show it) — it lives in a separate enforcement layer from the one Stage 2 establishes, and nothing in either README explains the split.Target Audience
Security auditors reviewing the environment's firewall posture; operators reasoning about why a blueprint rule doesn't appear in the folder policy.
Proposed Location
A note in
blueprints/il5/postgresql/README.mdand/or the Stage 2 README.Content Outline / Draft
firewall-policies rules listvs.firewall-rules list).google_compute_firewall_policy_ruleagainst Stage 2's existing hierarchical policy — happy to discuss which direction maintainers prefer.Compliance Context (if applicable)
Auditability/governance-transparency gap rather than a control failure; relevant to firewall-review procedures under FRH/IL4/IL5 (e.g., CM-6/SC-7 evidence gathering). Verified at
3728fc98: both networking variants govern via the same hierarchicalfirewall-policy-defaultmodule (2-networking-a-fedramp-high/main.tf:44and2-networking-b-il5-ngfw/main.tf:43), so the split applies regardless of regime; the postgresql blueprint ships in both the FRH and IL5 trees.