Skip to content
This repository has been archived by the owner on Dec 7, 2020. It is now read-only.

Support mapping additional request paths to different upstream URLs. #524

Open
chirino opened this issue Apr 8, 2020 · 5 comments
Open
Assignees

Comments

@chirino
Copy link
Contributor

chirino commented Apr 8, 2020

Currently the configuration only supports specifying one upstream URL.. This works if your only proxying to a single upstream service:

# the upstream endpoint which we should proxy request
upstream-url: http://myapp:80
resources:
- uri: /
  roles:
  - user
- uri: /admin
  roles:
  - admin

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 and http://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 upstream endpoint which we should proxy request
upstream-url: http://myapp-user:80 # The default upstream if a better match is not found:
upstream-url-paths: 
- uri: /admin
  upstream-url:  http://myapp-admin:80
- uri: /data
  upstream-url:  http://myapp-data:80
resources:
- uri: /
  roles:
  - user
- uri: /admin
  roles:
  - admin
@abstractj abstractj self-assigned this Apr 8, 2020
chirino added a commit to chirino/keycloak-gatekeeper that referenced this issue Apr 8, 2020
chirino added a commit to chirino/keycloak-gatekeeper that referenced this issue Apr 8, 2020
chirino added a commit to chirino/keycloak-gatekeeper that referenced this issue Apr 8, 2020
@stianst
Copy link
Contributor

stianst commented Apr 21, 2020

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.

@chirino
Copy link
Contributor Author

chirino commented Apr 29, 2020

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

@stianst
Copy link
Contributor

stianst commented Apr 30, 2020

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.

@xeor
Copy link

xeor commented Jun 25, 2020

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).

@abstractj
Copy link

@xeor @chirino submitted a PR for this #526. If you would like to give it a try and provide some feedback, you are more than welcome

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants