jakman85andClaude Opus 5
f92707f38c
Lets the operator's Android / Linux / Windows / macOS devices dial in from anywhere and behave like LAN machines: full reach to 192.168.2.0/24 plus internet egress out the house WAN. Opposite direction to platform/vpn-egress, which sends pods OUT through PIA; the two share nothing but the word "VPN". WireGuard because it is the only option with a first-party client on all four named platforms, and because its handshake MAC is keyed with the responder's own public key: an unauthenticated packet gets NO reply, so udp/51820 is indistinguishable from a closed port. That, not "it is encrypted", is what makes an unfiltered WAN port defensible, and why there is no source allowlist. hostNetwork: true is REQUIRED, not convenient. A pod-networked server must SNAT clients to its own pod IP, so every remote client would carry that pod's Cilium identity -- and a pod-sourced request to the shared Gateway VIP returns 403 from Envoy for ALL 16 hostnames (measured 2026-10-04), because Cilium's Gateway preserves the original source identity and enforces the destination's ingress policy. The obvious build would have shipped a healthy-looking tunnel on which every cluster web UI was 403 and *.home.keithjackson.dev did not even resolve. In the host netns traffic is SNATed to the node and arrives as host/remote-node, exactly like a LAN client. It also sidesteps the unsafe ip_forward sysctl, the L2-announcement lease lottery, and double encapsulation (hence MTU 1420). Permitted by restrict-host-namespaces' own carve-out for platform namespaces. The cost is stated in networkpolicy.yaml rather than papered over: no NetworkPolicy constrains a hostNetwork pod. A DaemonSet so the hand-made WAN forward cannot be invalidated by a reschedule; all three nodes answer the same keys, so failover is a one-line router change. Peer PUBLIC keys are plaintext in peers.yaml, which makes "who can get into my house" a reviewable PR diff. The only secret -- the server's private key -- is an out-of-band Secret: an agent must not mint a long-lived private key, and the two halves are joined only at pod start into a tmpfs that dies with the pod. Ships INERT-BUT-HEALTHY with zero peers. THREE off-repo manual steps remain (kernel module, server key, WAN forward) -- runbooks/vpn-remote-access.md. Touches clusters/** , so ci/approval-policy.sh will block pending the operator's /approve-override. Deliberately not posted by me (CLAUDE.md §1). Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
74 lines
4.6 KiB
YAML
74 lines
4.6 KiB
YAML
---
|
|
# ============================================================================================
|
|
# THE PEER REGISTER — every device allowed to dial in, in PLAINTEXT, in git, on purpose.
|
|
# ============================================================================================
|
|
# WireGuard has no usernames, no passwords and no PKI. Authorisation is exactly one thing: a
|
|
# device's PUBLIC key appears in this file, or it cannot complete a handshake. An unlisted key
|
|
# gets no reply at all — not a rejection, silence (see README "Why this is safe to expose").
|
|
# Revoking a device is therefore deleting its stanza, and nothing else.
|
|
#
|
|
# WHY PLAINTEXT, AND WHY THIS IS NOT A SECRET LEAK. A WireGuard peer's PUBLIC key is public by
|
|
# construction — it is the half you are supposed to hand to the server, and holding it grants
|
|
# nothing. The only secret in the whole scheme is the SERVER's private key, which is NOT here:
|
|
# it lives in the `wg-server-key` Secret and is assembled into the running config at pod start
|
|
# (daemonset.yaml). Keeping the register in cleartext buys the property that matters most for an
|
|
# access-control list: **"who can get into my house" is reviewable in a pull-request diff**, and
|
|
# its history is `git log` on this file. A SOPS-encrypted register would hide exactly the change
|
|
# a reviewer most needs to see — a new line granting a new device entry to the whole LAN.
|
|
#
|
|
# This is the same division of labour the repo already uses for the opposite case: a Secret's KEY
|
|
# NAMES are cleartext while values are encrypted (.sops.yaml `encrypted_regex`), so diffs stay
|
|
# readable. Here the whole file is the key-name half.
|
|
#
|
|
# ADDING A DEVICE — never hand-roll this, and never generate a key in a chat transcript.
|
|
# ./infra/vpn-ingress/new-peer.sh <device-name> <last-octet>
|
|
# It generates the keypair ON THE OPERATOR'S MACHINE, writes/renders the client profile (and a
|
|
# QR code for phones), prints ONLY the public half for pasting below, and never transmits or
|
|
# logs the private half. Then: add the stanza, PR, merge; Flux rolls the DaemonSet.
|
|
#
|
|
# ADDRESS ALLOCATION. ${WG_CLIENT_CIDR} is the tunnel subnet; .1 is the server (every node).
|
|
# Give each device ONE address as a /32 in AllowedIPs. A /32 is not a formality — on the SERVER
|
|
# side AllowedIPs is the cryptokey ROUTING table AND the inbound source filter: a peer may only
|
|
# send from, and receive traffic for, the addresses listed in its own stanza. A sloppy /24 here
|
|
# would let any one device impersonate every other device's tunnel address.
|
|
#
|
|
# .1 the server (this DaemonSet, on every node)
|
|
# .2 - .254 devices, one each, allocated below. Keep this list dense and in order so the
|
|
# next free octet is obvious; never re-use an octet after revoking a device
|
|
# (an old client profile would silently start working again as someone else).
|
|
#
|
|
# PRESHARED KEYS are deliberately NOT used. They add a symmetric post-quantum hedge on top of
|
|
# the Noise handshake and would be a genuine secret — which would force this register into SOPS
|
|
# and cost the reviewability above. Revisit only if the threat model changes; if it does, the PSK
|
|
# belongs in the `wg-server-key` Secret, not here. See README "Hardening not taken".
|
|
apiVersion: v1
|
|
kind: ConfigMap
|
|
metadata:
|
|
name: wg-peers
|
|
namespace: vpn-ingress
|
|
labels:
|
|
app.kubernetes.io/name: vpn-ingress
|
|
data:
|
|
# Appended VERBATIM to the generated [Interface] block, in this order, at pod start.
|
|
#
|
|
# *** THERE ARE NO PEERS YET. THAT IS THE CORRECT INITIAL STATE, NOT AN OVERSIGHT. ***
|
|
# An agent must not mint key material (CLAUDE.md §6), so no device could be enrolled as part of
|
|
# authoring this component. A zero-peer WireGuard interface is valid and starts cleanly: the
|
|
# DaemonSet will run and listen, and every handshake will be refused because no key is trusted.
|
|
# The VPN is therefore INERT-BUT-HEALTHY until the first stanza lands — fail-closed, and visible
|
|
# (`wg show` reports an interface with no peers).
|
|
#
|
|
# COPY THIS TEMPLATE, uncomment, one block per device:
|
|
#
|
|
# # pixel-8 — Keith's phone, enrolled 2026-10-05
|
|
# [Peer]
|
|
# PublicKey = <the public key new-peer.sh printed>
|
|
# AllowedIPs = 10.90.0.2/32
|
|
#
|
|
# Keep the `# <name> — <owner>, enrolled <date>` comment line. It is the only place a key is
|
|
# tied to a human-recognisable device; `wg show` can only ever print the key itself, so without
|
|
# it an incident responder cannot tell which stanza to delete.
|
|
peers.conf: |
|
|
# No peers enrolled yet. See the template in this file's comments and
|
|
# ./infra/vpn-ingress/new-peer.sh. One [Peer] block per device.
|