Narrow inbound SSH to the private range and delete the world-facing rule

[aterga]

Rewritten. This issue originally proposed SSM Session Manager, on the premise that no CIDR could be allowlisted. Both the premise and the recommendation have since changed; the body below states the current position, including how the premise fell over — worth reading before acting. The identifiers this issue used to carry were replaced with prose ahead of the repository going public, and its comment history was removed in the same pass (#101), so this body is now the authoritative record.

Is your feature request related to a problem?

Inbound 22/tcp is permitted from 0.0.0.0/0 in a security group shared by both deploy hosts. Removing that was the stated payoff of #84 — the build/ship split exists so the ship job can reach the host on its private address over the VPN rather than over the internet.

Two things have since changed the shape of this.

Internet-facing SSH is already closed. Each host has two network interfaces: a public-facing one carrying the HTTPS address and a private one the deploy reaches over the VPN. Security groups attach per-interface, so the public one now carries a group permitting 80/443 only. Verified from outside the VPN — 22 times out where it previously reached sshd, with an HTTPS 200 on the same host as the control that proves the host is up and the difference is the port. The rule itself is untouched and still applies to the private interfaces.

The "no stable CIDR" argument does not hold. It rested on one observed public source address, which turned out to be an artifact: staging's DEPLOY_HOST named the public FQDN, so its deploys left over the internet rather than the VPN and presented a public source. Repointed to the private address, staging presents a private one, as production always did. Both VPN-path deploys observed so far land in the same private /24.

Describe the solution you'd like

Delete the 22-from-0.0.0.0/0 rule and rely on the private range instead, which both hosts already permit.

Not yet, and not blindly:

1. Accumulate readings first. Only two VPN-path observations exist, both from the same runner group and the same /24. Calico source-NATs each pod to whichever worker node it landed on, node addresses are provisioned dynamically rather than declared, and the two clusters are separate sites with separate ranges — so a reading from the other cluster is the one that matters. This is why the Calico reasoning is retained: not as proof that narrowing is impossible, but as the reason to verify rather than assume. The Report source address as seen by the host step from Report the ship runner's source address, and fix the dual-stack guidance #90 makes this decidable and should stay permanently.
2. Add our own rule rather than depending on the existing one. The rules currently permitting 22 from the private range belong to another team and can change without reference to this deployment.
3. The group is shared between both hosts, so editing it affects staging and production simultaneously. That is how the earlier attempt broke staging while a production release was in flight. Change it deliberately, not during a release.

Alternatives considered

• SSM Session Manager — declined. Needs no inbound port at all and records each session in CloudTrail, and ssh keeps working over it via a ProxyCommand so deploy.sh would need no changes; only the workflow's SSH setup. It is the stronger end state. Declined as over-engineering for the residual risk once internet-facing SSH was closed: the remaining exposure is to the VPN and on-prem estate, which is accepted. The work it would need — IAM instance profile, GitHub OIDC role, session-manager-plugin, DEPLOY_HOST changing form — is recorded here in case that judgement changes.
• A job that opens a short-lived rule for its own address. Circular: the runner cannot discover which address to open, since its public egress is not the address the host sees on the VPN path. It also leaves a rule behind if the job dies, and races concurrent deploys.
• A bastion. Inherits the same problem — it needs inbound SSH from the same sources.
• Leave the rule as it is. Now much more defensible than when this was filed, since the internet path is gone. Still worth closing: a world-facing rule sitting in a shared group is a trap for whoever next attaches that group to something public.

Additional context

• The ::/0 half of the rule was removed early on: the IPsec tunnels and BGP sessions to this VPC are IPv4-only, so the deploy never arrived over IPv6 and that half permitted nothing but internet-sourced attempts. The rules permitting 22 from the private range have no IPv6 entry either, so nothing on the v6 side depended on it. Not empirically retested from outside since — worth confirming rather than assuming.
• One loose end: the deploy interface on staging still has an unused public address associated. It is inbound-dead because that subnet's default route goes to a NAT gateway, but repairing that routing or moving the interface would silently restore an internet path to SSH. Worth disassociating.
• deploy/native/README.md's "Narrowing inbound SSH" section is the prose version of this and was brought in line in Rewrite the inbound-SSH section: it described a state that no longer exists #104.
• Background: Ship staging from the on-prem runner over its private address #84 (build/ship split), Deploy production on release-* tags #81 (production release pipeline), Report the ship runner's source address, and fix the dual-stack guidance #90 (the source-address step), Stop documenting a decommissioned host address as the DEPLOY_HOST example #102 (the private-address requirement, documented on the secret itself).

[aterga]

Recorded: one stale SSH claim retained in git history, deliberately

Noting this as a decision rather than an oversight, ahead of the repository going public.

#84's commit message states that the shared security group carries 22/tcp from 0.0.0.0/0 and ::/0, and that staging was the reason any host here needed SSH open to the public internet. That was accurate when written. It is no longer: the ::/0 half was removed, and internet-facing SSH is closed on both hosts via per-interface security groups permitting 80/443 only — verified from outside the VPN, 22 timing out against an HTTPS 200 control on the same host.

Not removed, for three reasons.

It is not sensitive data. It contains no address, identifier or credential — it is a prose claim that has since been superseded, which is a different category from the internal address that was removed from history for exactly that reason.

It is anchored by release-2026-07-29, the tag production is deployed from. The commit is reachable from that tag, so removing it would mean either moving the tag — severing the link between what is running in production and what is in the repository — or leaving the tag dangling.

The cost is disproportionate. The commit is 17 back from the tip, so removing it means rewriting 17 commits, and it would still survive in the pull request refs afterwards, which no git operation can reach. That is the same limitation documented in #101: refs/pull/*/head is read-only and permanent.

Why it reads correctly anyway. Commit messages are dated statements about the state at the time of the change. This one is followed, 17 commits later, by #104 — whose subject is literally "Rewrite the inbound-SSH section: it described a state that no longer exists." Read in sequence, the history is self-correcting. The body of this issue is the authoritative current position.

For contrast, and so the asymmetry is on the record: the internal address in #102's commit message was removed — main was rewritten, the branch anchor deleted, and a support request filed for the pull request refs — because a private address is a lateral-movement target where a stale claim is not.

---

Generated by Claude Code