fix(playbooks): Block metadata IP egress from the host itself

[regdocs]

What

The iptables role already blocks the cloud metadata IP (169.254.169.254), but only on the FORWARD chain scoped to in_interface: docker0 — i.e. it stops benches/containers from reaching metadata. The host's own processes (the gunicorn web + background workers) reach the metadata service via the OUTPUT chain, which was unguarded.

That OUTPUT path is exactly what the webhook SSRF used to reach 169.254.169.254 from the control-plane host. This adds an OUTPUT-chain REJECT so a request originating on the host itself can't reach the metadata service either.

REJECT (not DROP) so a stray request fails immediately instead of hanging on the timeout. The existing Save iptables rules task persists it to /etc/iptables/rules.v4.

Relationship to the SSRF fix

This is the network-layer complement to the application-layer fix in #7459 (which resolves the webhook host, rejects non-global IPs, pins to the resolved IP, and disables redirects). The code fix is what closes the vulnerability; this ensures the next SSRF-shaped bug hits a wall at the network too.

Rollout note

This role runs on every server that runs iptables.yml, and the rule also blocks the host's own runtime metadata use. That's safe where metadata is only read by cloud-init at boot (DigitalOcean / Hetzner / Frappe Compute) and where cloud API access uses static credentials rather than an instance role (press stores aws_secret_access_key in the DB). Confirm no server type fetches IMDS at runtime before applying fleet-wide, and lift the rule during any maintenance that reconfigures networking (e.g. a floating/reserved-IP reassignment).

🤖 Generated with Claude Code

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[greptile-apps]

Confidence Score: 5/5

Safe to merge.

_{Reviews (1) · Last reviewed commit: "fix(playbooks): Block metadata IP egress..."}