Open chirino opened 4 years ago
In general the vision behind Gatekeeper was that it would be deployed as close to the service/app as possible. It also does not aim to be a general reverse proxy (aka grouping micro services into separate namespace). So not sure if this is something we really do want to add.
In general the vision behind Gatekeeper was that it would be deployed as close to the service/app as possible. It also does not aim to be a general reverse proxy (aka grouping micro services into separate namespace). So not sure if this is something we really do want to add.
This style of proxing is supported by the OpenShift oauth proxy. It’s something we would desire to avoid additional reverse proxy that could supply such a common requirement
Gatekeeper was designed to be a sidecar/agent proxy, not a general purpose proxy. The reason for that is to not have an air-gap where the services can be accessed without security.
If someone compromises a single service then they can now move around vertically without anything stopping them.
As OpenShift oauth-proxy recommends using it as a sidecar I'm not sure I see how it should support multiple upstream URLs.
This is one of the few thing I miss. Would love to see this implemented so I can get rid of some complexity (a dedicated nginx reverse proxy).
@xeor @chirino submitted a PR for this https://github.com/louketo/louketo-proxy/pull/526. If you would like to give it a try and provide some feedback, you are more than welcome
Currently the configuration only supports specifying one upstream URL.. This works if your only proxying to a single upstream service:
But sometimes, apps built in a micro service style are are composed of multiple services routed to by path. For example:
http://myapp-admin/admin
andhttp://myapp-user/
could be two different independently scaled services in the app built by different groups, but should composed into a single URL namespace.I propose that the configuration also support the following: