louketo-proxy
louketo-proxy copied to clipboard
louketo
feat #524 Support mapping additional request paths to different upstream URLs
all the white space reviews by the golangcibot are super annoying. Is there some CLI tool that could fix these automatically for me?
This PR allows one keycloack gatekeeper be the security gateway to multiple upstream http servers. This is a common setup when you app is broken down into multiple microservices which that all want to share the same security policies. It would not be very DRY to have to repeat gatekeeper configuration per microservice.
The idea with Gatekeeper is that it should be deployed alongside the application, and should not be a gateway to multiple applications/services. If you deploy Gatekeeper separate you are opening up for applications to be accessed insecurely when someone gets inside the network boundaries.
For separate micro services these should also be using separate client-ids as you do not want a single token to be able to invoke all micro services, but rather control what can invoke what.
That being said there is discussions and potential that we will allow plugin Gatekeeper into a general purpose proxy/gateway, such as HAProxy/OpenShift Router/Envoy, through a gRPC remoting interface.
We should continue the discussion on this one in the issue: https://github.com/keycloak/keycloak-gatekeeper/issues/524
After thinking about this some more we should support this to make it easy to migrate from other proxies, then recommend using mtls to prevent ability to bypass security by invoking upstream directly.
I haven't reviewed this fully yet, just a quick scan. I also don't have too much context on this project and how it's configured yet, but, from experience with OAuth2-Proxy, I would suggest we don't have a flag for this and instead force users to use a configuration file.
Overloading of strings in flags makes for complicated parsing code and also makes documenting the feature difficult. We have to make up our own formats for separating the different parts of the option and users will make mistakes configuring this that will be hard to understand.
I would much prefer to see this as a structured object within configuration only rather than a flag with complex parsing.
For context, I raised some discussion around this https://github.com/oauth2-proxy/oauth2-proxy/issues/532 as the complexity of configuration has been one of the major problems with the project since I took it over
