-
Notifications
You must be signed in to change notification settings - Fork 349
Support mapping additional request paths to different upstream URLs. #524
Comments
…t upstream URLs
…t upstream URLs
…t upstream URLs
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). |
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:
The text was updated successfully, but these errors were encountered: