WS3 phase 1b: register the UniFi gateway peer on the control-plane wg0 listener

[devantler]

🤖 Generated by the Daily AI Assistant

Problem

#2462 ships the control-plane WireGuard listener (wg0, 51820/udp) without a peer: the gateway's key pair does not exist until provider-upjet-unifi applies the unifi tenant's cluster_wireguard resource, and that tenant work is itself sequenced behind the listener landing (unifi#14 pauses it until WS3's server exists) — requiring the peer in #2462 would deadlock both sides. A peer-less listener is safe (WireGuard answers no unauthenticated packet) but no tunnel can come up until the peer is registered.

Proposal

Once the provider is functional (platform#2467) and the unifi tenant's cluster_wireguard applies (server public key + endpoint filled, pause lifted — unifi#14), take the tenant output cluster_wireguard_gateway_public_key and:

1. set it as the prod environment secret WG_GATEWAY_PUBLIC_KEY;
2. add the peer block to talos/control-planes/wireguard.yaml (publicKey: ${WG_GATEWAY_PUBLIC_KEY}, allowedIPs: [10.200.0.2/32]) and thread the new secret through the deploy-prod composite + ci/cd/dr-rebuild the same way as WG_SERVER_PRIVATE_KEY;
3. out-of-band talosctl patch mc the running control planes (machine-config-only changes are not pushed by ksail cluster update), then verify the handshake from the gateway side.

Acceptance criteria

• wg0 on all three control planes has the gateway peer; wg show reports a completed handshake.
• The UniFi gateway can reach 10.200.0.1 over the tunnel.
• Part of the WS3 lane (feat(talos): WireGuard server listener on control planes (WS3 phase 1) #2462 → this → datapath/enforcement docs: design for requiring VPN in front of critical services #2465-follow-on).