feat: multiple application configurations, single vouch proxy instance

[vasi-grigo]

First off, thank you for this project; i can see it making my devops life much easier :) Secondly, are you guys considering adding a mode in which the proxy would run with multiple SSO configurations? To add a bit more context:

• system runs in GKE
• nginx-ingress is used as the front
• vouch proxy is used as the SSO enforcer
• there are multiple applications each with its own SSO particulars (client_id, secret, etc., etc.)

Currently, to support this scenario, one has to deploy multiple instances of vouch-proxy. One per configuration to be exact. This is:

• suboptimal in terms of resource usage (this is exacerbated by things like autopilot which sets minimum CPU usage to 250m; so say, 10 apps will require 2500m idling most of the time)
• hard to maintain; basically each application needs to either create another deployment alongside or use a sidecar

Ideas:

• upstream header; nginx (or whichever upstream server) sets a X-Vouch-Use-Config header that corresponds to a local config file inside the container where vouch-proxy is running
• $host header; new configuration option like multihost=true causes vouch-proxy to run in multihost mode which uses $host to lookup its corresponding config file; e.g. request for app0.foo.bar uses /config/app0.foo.bar.yaml

It seems like something relatively easy to add to the project and would greatly benefit plenty of users apart from me and make it a bit more "cloud-native" cheers

[adamency]

Hi @vasi-grigo. Have you been able to find a solution for this ?

To explain my usecase: I have been using oauth2-proxy myself instead, but to my understanding it can only serve multiple upstreams if they are hosted on different paths, i.e. using two different domains app1.dn.com and app2.dn.com isn't allowed, and we have to use dn.com/app1 and dn.com/app2 which breaks all application which don't support being served on a subpath.

So I'm also looking for an auth proxy which can do this.

[bnfinet]

This comes up from time to time and I just end up not being in love with this idea. Feels like too much of a foot gun.

VP is fairly low resource usage. Is it a pain to deploy multiple instances in parallel? Yes it is. But at least you can be sure that your request was routed to the correct security context.

[adamency]

@bnfinet It's not a big issue if you just have two apps to protect, right. But the thing is I have several third party apps which don't implement authentication themselves, multiplied by all our tenants. Which in total amounts to a couple dozens separate applications. Deploying 40 instances of an auth proxy to the cluster is indeed a complicated design decision to justify, or even consider.

But thanks for your answer anyway.

[vasi-grigo]

This comes up from time to time and I just end up not being in love with this idea. Feels like too much of a foot gun.

how is it a foot gun to have all requests go through a centralized gateway for auth? (instead of having a separate deployment for each application)?

VP is fairly low resource usage. Is it a pain to deploy multiple instances in parallel? Yes it is. But at least you can be sure that your request was routed to the correct security context.

it's not really about VP being low resource usage; in autopilot-like environments there's a default minimum for a pod which makes the math min resource * num of vp instances; for an HA setup this feature would be min resource * 2 you can be pretty sure that the request is securely/properly routed as each application would be under a separate DNS

[bnfinet]

@vasi-grigo thanks for your interest in VP

It sounds like it may be worth it to you both financially and on the merits to explore forking the codebase and seeing if you can achieve a multi tenant objective. If you're able to do that, I would be so curious to learn about the solution you came up with and see if it's feasible for wider deployment.

But I should set the expectation that I am skeptical that such a change would keep VPs config approachable, clear and secure and that I'm not personally interested in taking VP in that direction and I'm not at all interested in supporting the requests that would invariably present themselves as issues in this repository. I'm sure many would agree that VP could use better support already.

If you would like to explore this concept further in this thread, could you please explore at least a concept for a working config based upon RBAC or ACL that might perform what you like and make a clearer proposal. I doubt it'll make it into VP any time soon but perhaps it would serve to move this conversation forward and offer the next human to propose it a more productive starting point.

But honestly I have other things that I'd prefer to do with VP long before multi-tenancy. I'm sorry that's the case.