Move lifecycle/admin APIs to separate ports

[fabxc]

I'd like to propose moving lifecycle and admin APIs to separate ports. Currently they are garded by boolean flags that enable them on the regular web port.
If one wants to enable them but still restrict access, e.g. to only give a sidecar on the same machine access to trigger reloads, one needs to add a reverse proxy with more complex rules.

It would be nice if we could allow such simple cases by simply not having those bits listen on external interfaces.

[brian-brazil]

I'm not sure we should be getting into adding authorization-related features that only work for specific users that happen to have a certain network model.

[fabxc]

This is not adding an authorization feature. It simply draws a boundary that's easier for people to build their authz stuff on.

And I don't think that listening on localhost is a "certain network model" that only a subset of users have.

[brian-brazil]

And I don't think that listening on localhost is a "certain network model" that only a subset of users have.

All users on localhost being trusted is not a model everyone has.

[fabxc]

It is still much easier in the general case to overlay authorization on ports instead of of HTTP paths. The latter are only accessible to tools that can introspect HTTP traffic in some way. So any mechanism using TCP proxies, iptables, or whatnot cannot be used.

Not providing authz is fine, but we should target for an approach which the highest number of tools can integrate with.

[brian-brazil]

It is still much easier in the general case to overlay authorization on ports instead of of HTTP paths.

Why privilege one set of APIs? Users may wish to limit the ways in which ways the query APIs can be used, and at the end of the day that implies something that understands HTTP.

[fabxc]

This is a much less likely use case though that wanting to limit access to the admin and lifecycle APIs, which everyone will want to do in some fashion.

[brian-brazil]

It'd still be offering at least two ways to do things, it's not maintainable to offer N different ways of doing things each of which is justified by it making some particular use case easier. That's why I want us to stick to one way of doing things, which users can build on top of rather than trying to accommodate everything out of the box.