chore: Move bind URLs to sockets

[sergerad]

Closes #1431.

[Mirko-von-Leipzig]

Thanks, that looks much better!

[kkovaacs]

With this change we seem to be losing the possibility to bind to specific addresses.

While probably not relevant for Docker but otherwise this means that we're now forcibly binding internal services to the wildcard address 0.0.0.0, which means:

• those services are public by default (unless you're using a firewall);
• there's no way to bind to IPv6.

I think we should really do use proper socket addresses (std::net::SocketAddr, complete with an IP address) instead of just the port for configuration.

[Mirko-von-Leipzig]

With this change we seem to be losing the possibility to bind to specific addresses.

While probably not relevant for Docker but otherwise this means that we're now forcibly binding internal services to the wildcard address 0.0.0.0, which means:

* those services are public by default (unless you're using a firewall);

Is that a problem though? In practice, you must always be using a firewall or be in control of the ports you're exposing publicly.

* there's no way to bind to IPv6.

Do we need that 😅

I think we should really do use proper socket addresses (std::net::SocketAddr, complete with an IP address) instead of just the port for configuration.

tbh I was hoping to keeps things as simple as possible. But I guess 0.0.0.0:0 and whatever the IPv6 format is would make sense as well.

[sergerad]

I think address is unnecessary (same as mentioned above, always firewall or Docker in k8s). But I do think "socket" or "address + port" envs/args make more sense semantically than "URL" as we have today. Not actually fussed about whether we include address or not.

[Mirko-von-Leipzig]

@sergerad I think @kkovaacs's points are valid. Lets make it SocketAddr instead of port.

[kkovaacs]

I think address is unnecessary (same as mentioned above, always firewall or Docker in k8s). But I do think "socket" or "address + port" envs/args make more sense semantically than "URL" as we have today. Not actually fussed about whether we include address or not.

Absolutely, I completely agree that the URL is unnecessary. I'm just suggesting that we should probably include address as well. It's unusual for network services not to provide that option and is limiting deployment options for no obvious advantage.

We could also just have best-of-both-worlds by implementing a custom value parser that allows for a missing address and defaults it to [::] for Clap?

[Mirko-von-Leipzig]

I think address is unnecessary (same as mentioned above, always firewall or Docker in k8s). But I do think "socket" or "address + port" envs/args make more sense semantically than "URL" as we have today. Not actually fussed about whether we include address or not.

Absolutely, I completely agree that the URL is unnecessary. I'm just suggesting that we should probably include address as well. It's unusual for network services not to provide that option and is limiting deployment options for no obvious advantage.

We could also just have best-of-both-worlds by implementing a custom value parser that allows for a missing address and defaults it to [::] for Clap?

I think lets be explicit and require a full address. That also prevents us from doing something unusual at deployment time.

[sergerad]

It's unusual for network services not to provide that option and is limiting deployment options for no obvious advantage

Yea, also agreed.

[bobbinth]

Re address vs. just port: under what scenarios would we use something other than 0.0.0.0 for the address? IIRC, one of the motivations for this was that using anything but 0.0.0.0 was almost always a mistake.

[sergerad]

Only real use case I would imagine is host-local (127.0.0.1) so only processes on the host could reach it. But all our services will be in separate hosts so I'm not sure we would ever do this.

I would think that binding to another specific IP would never actually happen either. Its fragile (network and host specific configuration on our service) to be binding a socket to a specific network interface. So even if we could do it, we probably wouldn't. And firewall rules do a better / more robust job of this.

Having said that, I agree it still doesn't hurt to allow address to be specified.

[sergerad]

We could also just have best-of-both-worlds by implementing a custom value parser that allows for a missing address and defaults it to [::] for Clap?

@bobbinth has mentioned he would prefer to require the address to be provided if we are going to support it so will keep it simple.

[Mirko-von-Leipzig]

@bobbinth we're unlikely to use this ourselves, but it does enable IPv6 which I think is nice to support. And there will local node users who won't be happy if their local node opens a publicly visible port, even though this should only be a problem if they have a bad firewall - but rather safe than sorry.