Page MenuHomePhabricator

Provide a stable address range for Phacility outbound requests
Closed, ResolvedPublic


Outbound requests from the Phacility cluster should originate from a stable address range and users should have access to this from the console so they can write IP-based access control rules as part of their access control policies.

For example:

  • if you use Harbormaster to drive an external build system like Jenkins, you should be able to whitelist Phacility origin addresses as part of your access control strategy.
  • if you use Drydock to interface with external hosts, you should be able to use firewall rules to restrict access to Phacility origins.

Event Timeline

This would be for whitelist/whitelisting IPs. For example creating a security group on AWS that only allows 443 (https) traffic from a phabricator cluster to a jenkins instance.

@amckinley, I'd like to try to do this as part of T12798. Here's my rough understanding of what we need to do:

  1. Launch something to serve as a gateway. Is this an actual instance, or some kind of virtual device that's more like an ELB? If it's an instance, do we run haproxy on it or, like, a perl script called or what?
  2. Bind one of the spare EIPs to it to serve as its internet-facing public IPv4 address.
  3. Configure some stuff on that thing (sorcery?).
  4. Launch a new actual instance that we're going to NAT, which will eventually become repo025 or repo-ohtwentyfive or whatever if our luck holds, with no public IPv4 address.
  5. Configure some stuff on the actual instance (wizardry?).
  6. Now the instance connects to the internet through the NAT host/device, and the internet sees the instance as having the EIP. Networking!

Are those steps roughly accurate, as far as you know? In particular, some of my assumptions are:

  • We can set up NAT on a host-by-host basis, and do not need to swap the whole VPC over at once.
  • We can run multiple outbound NAT hosts in the same VPC if we want to for some reason (we don't today, AFAIK, but my understanding is basically that we aren't locking in anything for the whole VPC here).
  • Some day we could maybe do a bunch of extremely fancy networking/routing nonsense and have redundant NAT gateways (so each host has multiple outbound routes, and losing a single NAT device does not prevent any host from reaching the public internet), but I don't expect we'll care about this until 2035 unless is really the state of the art and it needs to be restarted every 2 hours.
  • Some kind of story exists for IPv6, and is "do the stuff above, but more magic", but our horizon for caring about that is more like 2050.
epriestley claimed this task.

This was resolved as part of T13630. I didn't actually put it in the UI anywhere, but all requests will now originate from, and this isn't likely to change given the wind-down of Phacility hosting.