Give new GCP Postgres servers the dual-NIC layout under a flag - #6651

Fourth PR of the GCP Postgres dual-NIC fencing series. Stacked on #6636 (which is stacked on #6623), so its diff shows only this PR's commits.

It lets new GCP Postgres servers get the dual-NIC layout from #6636: control plane SSH on a management nic0, and customer traffic on the Dynamic NIC nic0.2. Everything stays off until an operator turns on a flag. The delete_nic lockout mechanism that uses this layout comes in a later PR.

Commits

1. Reach GCE management NICs over IPv6 without an EIP. Launch GCP VMs with a management NIC and a Dynamic user NIC #6636 had only the IPv4 management mode. A management NIC assembled with use_eip: false has no static IPv4, but the launch code still asked for an IPv4 NAT on nic0 and gave it no IPv6.
   • Such a nic0 is now dual-stack with an external IPv6 address and no IPv4 NAT, and that address becomes the SSH host. The management VPC already allows SSH from the IPv6 control plane CIDRs.
   • In the guest, router advertisements are off on nic0, because they would put a second IPv6 default route into the main table. Its address and gateway come from the metadata server, and its default route is only in the management table.
   • The spec now also runs the fill script against fake metadata in both modes.
2. Request management NICs for GCP Postgres under a flag.
   • The server assemble asks the resource, through provider dispatch, whether to use a separate management NIC and whether it gets an EIP. AWS answers as before, and metal never uses one.
   • On GCP, a new server gets a management NIC when the gcp_postgres_dual_nic Config or the postgres_gcp_dual_nic project flag is on and the location's management subnet is ready.
   • Once a server of a resource has a management NIC, every later server gets one too, also with both flags off.
   • The postgres_gcp_ssh_ipv6 project flag selects the IPv6 mode, as postgres_aws_ssh_ipv6 does on AWS.
3. Leave port 22 out of dual-NIC GCP Postgres firewalls. The internal firewall's tag rules reach only the customer VPC, so on a dual-NIC server port 22 there opens nothing the control plane uses.
   • mgmt_ssh_via_user_security_group? is now dispatched per provider. The AWS rule moves into its provider module unchanged.
   • A new dual-NIC GCP resource gets no port 22. Existing resources keep it.

Tested live

I ran a local control plane (respirate and monitor) from this branch against a GCP dev project, with the management network bootstrapped in gcp-us-central1 and gcp-us-east4.

• IPv4 management mode, with GCP_POSTGRES_DUAL_NIC=true: postgres_standard, postgres_ubuntu_2604, postgres_ha, postgres_upgrade, postgres_unarchive and postgres_firewall all passed.
  • Every server, also the new ones from the 26.04 migration, the upgrade and the unarchive, had nic0 in the management VPC and nic0.2 in the customer VPC.
  • Every internal firewall had only 5432 and 6432.
  • The HA failover ran its lockout over the management NIC.
  • postgres_firewall passed, so the customer firewall rules work on the Dynamic NIC.
• IPv6 management mode, in a project with postgres_gcp_ssh_ipv6: postgres_standard passed on postgres-ubuntu-2604.
  • nic0 was IPV4_IPV6 with an external IPv6 address and no IPv4 NAT, and SSH used that address.
  • In the guest, both main-table default routes use user-nic. nic0's IPv6 default route is only in table 100, with source rules for both management addresses.
• Not tested: the IPv6 mode on postgres-ubuntu-2204.

🤖 Generated with Claude Code