ced4568
d2280d0f0d
Named-bridge-network production Compose (not host networking, unlike dev) for rn-platform-01; egress-proxy + agents for rn-lab-host-01. Caddy reverse proxy, single public origin, Grafana restricted to management_cidr. iptables-restore firewall rulesets for all three hosts (Proxmox host, rn-platform-01, rn-lab-host-01) codifying the Platform/Lab-Host boundary: no student-to-student traffic, no direct Proxmox exposure, no direct Postgres/Provisioner exposure from the Lab Host. Mutual TLS for the Provisioner<->Lab Host Docker connection: certificate generation/verification scripts, dockerd TLS config, firewall-restricted port 2376. Application support already existed since Phase 1; this is purely the operational half. Validated: docker compose config, caddy validate, firewall structural lint, and a real openssl s_server/s_client mTLS handshake proving the cert chain and mutual-auth rejection (legitimate client verified, rogue client correctly rejected with verify code 19).
Production firewall policy
iptables (not nftables) — deliberately, to stay consistent with the Provisioner's own dynamic
per-Lab egress rules, which already manipulate the DOCKER-USER chain via iptables
(platform/provisioner/src/firewall.js, Phase 1). Mixing the nft and legacy iptables backends
on the same host is a known source of silent rule-ordering bugs; the host-level policy below
uses the same backend the app already depends on.
Each .rules file is iptables-restore format — deployed by the matching Ansible role
(firewall for the VMs; the Proxmox host ruleset is applied manually per
docs/PRODUCTION_DEPLOYMENT.md §2, since Proxmox host firewalling is out of Ansible's blast
radius by design — a mistake there can lock out the only way in).
| File | Applies to | Deployed by |
|---|---|---|
proxmox-host.rules |
The Proxmox hypervisor itself | manual, docs/PRODUCTION_DEPLOYMENT.md §2 |
rn-platform-01.rules |
Platform VM | infra/ansible/roles/firewall/ |
rn-lab-host-01.rules |
Lab Host VM | infra/ansible/roles/firewall/ |
All three encode the same policy table from docs/PRODUCTION_NETWORK_SECURITY.md §6 — this
README doesn't restate it, that doc is the source of truth for why; these files are the
what, in a form the host can actually load.
IP addresses/subnets are Ansible template variables ({{ platform_ip }},
{{ lab_host_ip }}, {{ management_cidr }}, etc.) — see infra/ansible/group_vars/production.yml.
Nothing here hardcodes a real production IP, per the explicit Phase 4 instruction not to guess
those before the real host exists.
infra/firewall/validate-firewall.sh renders each ruleset with dummy IPs and runs it through
iptables-restore --test (syntax/semantic validation only — proves the rules are well-formed
iptables, not that the real network topology is correct, which needs the real hardware).