Allow oauth2 filter in Contour

[stevesloka]

Currently, the external authorization support in Contour will allow users to implement an Oauth2 flow, however, users need to find an implementation as well as manage that inside their cluster.

An alternative could be to allow the Oauth2 filter in Envoy to do the same thing and not require the additional deployment / management of the external auth service.

We'd just need to figure out an api configuration spec to enable.

Originally posted by @stevesloka in #2664 (comment)

[jpeach]

xref #2664

[youngnick]

That's a pretty big "just" - there is a lot of config for the OAuth2 filter. I think the tradeoff here is complexity. Do we really want to be in the business of configuring OAuth directly? What are reasonable default values for everything? Do we just pass through all the fields and tell people they're on their own for configuration? That doesn't seem ideal either.

[stevesloka]

I think the tradeoff here is complexity.

Our current answer to that right now is, "you're on your own" which isn't all that great either. If you setup an external provider you've got the same amount of configuration, but have the additional overhead to also setup an extra set of pods (auth server), services, and ExtensionService to get it working and maintain them.

Do we just pass through all the fields and tell people they're on their own for configuration?

I'm not sure which is why I said we'd need to figure out the configuration spec of how we'd set it up. I'm not minimizing the effort or implementation here, but would rather take that work on as a project to have a happier user.

With this filter, we're not configuring oauth, we're just configuring Envoy. It's very similar to enabling the local rate limiting filter, you don't "need" it and could accomplish the same with the global filter but it's in the spec for the design that @skriss is working through.

[youngnick]

I agree that users aren't in a great spot right now - I just want to be conscious about what complexity we take on.

With this filter, we're not configuring oauth, we're just configuring Envoy.

You're technically correct here, but in order to configure Envoy to use the OAuth filter, we have to pass through all the OAuth filter fields, that is, we need to pass through the configuration for OAuth. That's what I meant by "configuring OAuth directly". I suspect this is similar to CORS in that we'll basically just need to pass through the config, since most of those fields seem like ones people will need to tweak.

I'm not saying we shouldn't do it, just that we have to design the feature.

[jpeach]

I agree that users aren't in a great spot right now - I just want to be conscious about what complexity we take on.

With this filter, we're not configuring oauth, we're just configuring Envoy.

You're technically correct here, but in order to configure Envoy to use the OAuth filter, we have to pass through all the OAuth filter fields, that is, we need to pass through the configuration for OAuth.

It would be interesting to hear from users who actually need OAuth/OIDC. What are the problems they encounter with the current situation?

[xaleeks]

@stevesloka does this imply a change from our existing external auth? Was this spurred by any particular request or feedback

[xaleeks]

Our current answer to that right now is, "you're on your own" which isn't all that great either. If you setup an external provider you've got the same amount of configuration, but have the additional overhead to also setup an extra set of pods (auth server), services, and ExtensionService to get it working and maintain them.

I'm still playing catchup but what is meant by 'you're on your own'. The extent of 'oauth2 support' I have in mind is the user presumably has an external auth server like dex or auth0 setup somewhere (maybe running on pods, maybe not) and he's trying to wire it up against Contour. That's all pre-existing. Or are you saying with the current ExtensionsService implmentation, the IDP has to be setup in a specific way? (it's not clear from our docs imho)

Btw, should we not support OIDC as opposed to general oauth2 which can differ depending on the vendor and the access token can return different set of scopes? It makes portability very difficult. As opposed to using the ID Token guaranteed by ODIC. And we start with a minimal set of scopes to support (ie. supporting groups), and than expand based on needs.

[stevesloka]

I'm still playing catchup but what is meant by 'you're on your own'. The extent of 'oauth2 support' I have in mind is the user presumably has an external auth server like dex or auth0 setup somewhere (maybe running on pods, maybe not) and he's trying to wire it up against Contour.

Having Contour & dex or auth0 isn't enough, you still need another component to deploy which implements the gRPC endpoint which Envoy will talk to and acts in the middle between Envoy<>dex/auth0. I've been working on getting the istio impl working but haven't been successful.

Btw, should we not support OIDC as opposed to general oauth2

The general goal of external auth is to allow users to use whatever protocol they want.

Yes you could use external auth and deploy those extra applications to get this working, but if you don't need to then that seems beneficial to users given regardless of how Contour implements, they still have the same configuration parameters to deal with. Since there's an oauth2 filter already in Envoy, we could possibly leverage that which is the discussion here.

This is exactly same as the situation as RateLimiting and leveraging the "local" rate limiting filter, we could opt to not allow that and only support global rate limiting, but then you need to take on the extra configuration of setting up that global rate limiter vs having configuration for local rate limiting as well as configuration for global rate limiting.

Great discussion on this! =)

[jpeach]

I'm still playing catchup but what is meant by 'you're on your own'. The extent of 'oauth2 support' I have in mind is the user presumably has an external auth server like dex or auth0 setup somewhere (maybe running on pods, maybe not) and he's trying to wire it up against Contour.

Having Contour & dex or auth0 isn't enough, you still need another component to deploy which implements the gRPC endpoint which Envoy will talk to and acts in the middle between Envoy<>dex/auth0. I've been working on getting the istio impl working but haven't been successful.

dex (and pinniped) can support the envoy protocol directly if we (?) add it. @georgegoh has a PoC of OAuth support in contour-authserver that he demonstrated for dex.

Btw, should we not support OIDC as opposed to general oauth2

The general goal of external auth is to allow users to use whatever protocol they want.

Yes you could use external auth and deploy those extra applications to get this working, but if you don't need to then that seems beneficial to users given regardless of how Contour implements, they still have the same configuration parameters to deal with. Since there's an oauth2 filter already in Envoy, we could possibly leverage that which is the discussion here.

The cost is different configuration paths, different semantics and more complexity overall. For a given amount of effort, is it more effective to add a different way to get oauth, or to improve the mechanism that already exists?

This is exactly same as the situation as RateLimiting and leveraging the "local" rate limiting filter, we could opt to not allow that and only support global rate limiting, but then you need to take on the extra configuration of setting up that global rate limiter vs having configuration for local rate limiting as well as configuration for global rate limiting.

Great discussion on this! =)

[georgegoh]

I think it may have been @robinfoe who built the PoC(not me).

[xaleeks]

Having Contour & dex or auth0 isn't enough, you still need another component to deploy which implements the gRPC endpoint which Envoy will talk to and acts in the middle between Envoy<>dex/auth0. I've been working on getting the istio impl working but haven't been successful.

Ok. It would be good to have that whatever else is needed to be handled by contour deployment as well. I hope we can support this (#2664) in a robust, self service way

From a user POV, I imagine this very minimal user story in some form

1. admin setup OIDC provider with list of users
2. admin setup claims and groups for his users
3. admin enter OIDC endpoint info on some contour CR object needed for oauth2 flow, ie endoint url, service callback url, secrets etc
4. user navigate to service and redirected to oidc endpoint
5. user authenticate himself
6. envoy redirects to upstream pod and user sees his application in browser

apologies if I'm misunderstanding the extent of our current external auth capabilities

[xaleeks]

some more high lvl requirements I can think of

• Support OIDC based authN and test against common IDPs like dex, auth0, keycloak etc. Also possibly Pinniped integration
• Minimal changes needed for contour configuration when switching btw identity providers
• Apply RBAC based on users (ie based on contents of the ID token or some other token)
• Support OIDC groups, which is commonly used for authZ

[jpeach]

some more high lvl requirements I can think of

• Support OIDC based authN and test against common IDPs like dex, auth0, keycloak etc. Also possiblyPinniped integration
• Minimal changes needed for contour configuration when switching btw identity providers
• Apply RBAC based on users (ie based on contents of the ID token or some other token)
• Support OIDC groups, which is commonly used for authZ

AFAIK there is enough machinery for all this in the external auth support. Can define OIDC practices on top of that.

[sudeeptoroy]

It would be a very useful feature to have.
I was able to configure envoy natively to protect my application via OAuth2 filter. As a user of contour, he would like to configure contour to do the same and get rid of managing envoy and its configuration. Here are the set of input needed to make it work with envoy.

1. OIDC token endpoint, timeout
2. Authorization endpoint
3. Backend application redirect uri, redirect path matcher, signout path
4. Client id
5. Auth scope
6. Resources (optional)
7. secret

[youngnick]

Thanks for that @sudeeptoroy, that's great information.

[alsyia]

you still need another component to deploy which implements the gRPC endpoint which Envoy will talk to and acts in the middle

Do you have some examples in mind, popular projects that do just that? We are specifically looking for an implementation that could be plugged into Auth0, and couldn't find one so far :)

[xaleeks]

Shall we close this and track the request on #2664?

[youngnick]

That seems reasonable to me. We have committed to doing the work on #2664, better to track this there.

Everyone watching this, can you please move over to #2664. No timeframe yet, but that's where we'll update. Thanks!