Proposal: Allow configurable bind address for Private API

[nicholasjackson]

Hi,

I would like to implement a service level segmentation for the private API sections of Keratin, this would require that private APIs bind to local host and all communication is proxied through a service mesh which will terminate TLS locally and also control access to the private API.

In order to implement this I would like to be able to configure the bind address for the server changing it from 0.0.0.0 to a user specified value using environment variables.

Proposed Change:
Implement two new environment variables for the configuration of AuthN.
BIND_ADDRESS = ip address to bind the API to
PUBLIC_BIND_ADDRESS = ip address to bind the public API to

In a service mesh scenario I would have the public bind set to 0.0.0.0 to allow public inbound traffic to the cluster however the private API would be bound to 127.0.0.1 and all traffic proxied through the mesh.

If this is an acceptable proposal I would be more than happy to carry out this work and issue a pull request.

Kind regards,

Nic

[cainlevy]

Yep, I'd like to see AuthN support the configuration you describe.

My main concern here is working towards a minimum (but necessary) set of environment variables. The current ones appear to be insufficient according to their name (PORT and PUBLIC_PORT) so I'd like to consider whether the two new variables could be positioned to replace them. Thoughts?

[nicholasjackson]

I would be easy either way, could always leave the old ones in with a startup warning for a version or two for backwards compatibility.

So we could have:
BIND_ADDRESS = ip and port to bind the api to default :3000
PUBLIC_BIND_ADDRESS = ip and port for public API

If none of the above are present then PORT would bind to :3000 by default or :[PORT] and PUBLIC_PORT would bind to :[PUBLIC_PORT]. The two new env vars would overide PORT and PUBLIC_PORT with the aim of these being depracted in two releases.

[cainlevy]

For now, I'm happy to introduce new variables that can function in a simple (port) or advanced (ip and port) fashion. Deprecation warnings for the old variables would be a bonus!

I'm not in a rush to hit 2.x, but that's when I'd drop the backwards compatibility.