Allow managment endpoints to be served on a different port

[tsickert]

Background

Flipt fundamentally has two different ways of interacting with it.

1. You're managing configuration of the feature flags
2. You're checking if a feature flag applies

Manging the configuration would obviously be done by the owners of the project. Checking if the feature flag is true is something a client used by customers could be doing directly (from a website, for example). Adding a reverse proxy with authentication is a good solution, but involves external tools. In some cases (like QA environments) I just want to spin up an instance of Flipt in ECS and then hit it directly from my QA environment.

Proposal

What do you think about allowing for a management port override like MANAGEMENT_PORT to be provided in the environment that would set the API to serve the management endpoints on a different port? That way, users could spin up the instance and then use AWS security groups (or the analogous alternative in other providers) to expose only the endpoint to get the configuration to the internet, while the management endpoints could only be accessible from some VPC subnet or even an individual IP.

Note: I'm thinking of the REST API for this, I'd have to go take a look at how gRPC servers requests, but I imagine it would be possible.

[markphelps]

@tsickert I really like this idea. It should be relatively easy, we'd have to break up the GRPC service into 2 services in the proto definitions.

Then we'd just start up each service on its own ports on both the GRPC and REST APIs, so potentially 4 different ports/goroutines.

A couple questions/concerns though:

1. I'd want to maintain backward compatibility, so by defaults everything would run on the same ports as they do now. So would have to think about how to accomplish this in code with 2 GRPC services and make them behave as 1. Perhaps we could do this with struct embedding?
2. Would this prevent us from moving to an 'actual' auth model in the future? For example by supporting JWT based auth or something? Perhaps not if 1 above can still be accomplished. Just trying to think of the different permutations that we'd have to support in the future.

What do you think?

[tsickert]

Thanks @markphelps!

Completely agree on 1. For the REST client, it would be a pretty easy if statement to either create a new server and adding the management endpoint to it on the new port, or just adding them to the server that exposes the client endpoints. For GRPC services, the embedded structs seem promising, but I'll have to look into that further.

On 2, I don't think this design would prevent auth from working in the future based on what I'm seeing. In the REST case, there would be a new router and new server. The router would need to register the same middleware that the router today does, plus any auth middleware, which should be fine. On the GRPC front, it seems like a similar pattern based on this. It might need to DRY out a bit when the second server/router/mux are added, but it seems like the actual auth process would be abstracted away from the servers.

I'd be interested in the auth implementation too. Since what I'm proposing is kind of a work around for it. I'm happy to keep this discussion scoped to the proposal and continue the auth discussion on the roadmap post if that's where you'd like it.