Epic: Oauth2 integration

[michmike]

As part of the larger work around enabling authentication in Contour, #2459, we need to built an authorization server for Envoy to support OIDC

[michmike]

cc: @jpeach

[jpeach]

xref #432
xref #2459
xref #2643

[stevesloka]

// cc envoyproxy/envoy#8571

[jpeach]

On Jul 9, 2020, at 4:07 AM, Steve Sloka <notifications@github.com> wrote: // cc envoyproxy/envoy#8571<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fenvoyproxy%2Fenvoy%2Fissues%2F8571&data=02%7C01%7Cjpeach%40vmware.com%7C4857a32cbceb47fa1be108d82369c82c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637298284524197037&sdata=9CMhky1oiUz0qTM%2FIK4nBzfGF7jbgPr%2FUl1Ujik8MmU%3D&reserved=0> Yep I’m aware of that one. But if we do external auth (which is needed IMHO), that can do OIDC. Adding a second direct OIDC API would be a big addition to the API surface area and not enable any new functionality.

[jpeach]

also https://github.com/ajmyyra/ambassador-auth-oidc and https://medium.com/@robert.broeckelmann/when-to-use-which-oauth2-grants-and-oidc-flows-ec6a5c00d864

[jpeach]

/cc @robinfoe

[swiftdiaries]

Hey
I'm trying to add OIDC based workflows with Contour. I was primarily looking at oauth-proxy, blog post on using oauth-proxy with NGINX.

The primary usecase is to use Contour as a lightweight replacement for Istio with Knative Serving, KF Serving to be precise.
I believe oauth-proxy adds options in terms of using GitHub, Google and other popular identity providers in addition to generic OIDC providers.

We're using https://github.com/ajmyyra/ambassador-auth-oidc + Dex (as th OIDC provider) in front of Istio IngressGateway in Kubeflow (KF Serving) currently.

[johanbrandhorst]

FYI this is possible to implement with the new external authorization server API in 1.9. You can use the Istio authservice for inspiration: https://github.com/istio-ecosystem/authservice. They put together a pretty cool flow chart here. The key is to return HTTP redirects to the client.

[youngnick]

We discussed this in a community meeting today.

Up until now, we have been directing people towards external authentication as a way to implement OIDC. However, as @xaleeks has mentioned on a few calls, having to install a separate controller for such a common use case is not ideal, particularly when the functionality can be accomplished using an inbuilt Envoy filter (https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/oauth2/v3/oauth.proto).

So, this update is to say that Contour is committing to implementing the inbuilt OAuth filter in Envoy at some point. To begin with, we will need a design for how to implement the filter, including where the configuration lives, what exactly needs to be configured, what testing we'll need, and so on. This should occur within the 1.20 timeframe.

After that, the next step is implementation. Depending on how long the design takes, this may make it into Contour 1.20.

Once the implementation is complete, we will close out #4044, #4045 by doing a manual test of those providers, preferably with some guides as to how to set them up.

[Agronis]

👍

[sudeeptoroy]

We discussed this in a community meeting today.

Up until now, we have been directing people towards external authentication as a way to implement OIDC. However, as @xaleeks has mentioned on a few calls, having to install a separate controller for such a common use case is not ideal, particularly when the functionality can be accomplished using an inbuilt Envoy filter (https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/oauth2/v3/oauth.proto).

So, this update is to say that Contour is committing to implementing the inbuilt OAuth filter in Envoy at some point. To begin with, we will need a design for how to implement the filter, including where the configuration lives, what exactly needs to be configured, what testing we'll need, and so on. This should occur within the 1.20 timeframe.

After that, the next step is implementation. Depending on how long the design takes, this may make it into Contour 1.20.

Once the implementation is complete, we will close out #4044, #4045 by doing a manual test of those providers, preferably with some guides as to how to set them up.

I have a reference config for oauth2, see if this helps. #3185 (comment)

[flokli]

@youngnick any update on this one? For the time being, are you aware of any Envoy-external-authorization compatible component that could be used for OAuth, so I could use Contour?

The only thing I could find was in oauth2-proxy, but upstream turned down the proposal: oauth2-proxy/oauth2-proxy#958 (comment)

Edit, ah I see, there's https://github.com/projectcontour/contour-authserver, which seems to have some support for OIDC.

[youngnick]

Hi @flokli, the current update is that I'm still working on the design, sorry. I'm trying to get a working configuration first so that I can validate what I have in mind will actually work, but in order to do that, I'm having to PoC out the whole filter and its config. It's taking a lot longer than I would have liked.

The user experience on the filter is not amazing either - if anything at all goes wrong, Envoy will tell you very little, which means that we'll also need to work on:

• upstreaming some UX improvements
• really good validation to help people not miss things.

Again, I'm really sorry about the delays, making a design has turned out harder than I thought.

[erwbgy]

@youngnick any update on this one? For the time being, are you aware of any Envoy-external-authorization compatible component that could be used for OAuth, so I could use Contour?

The only thing I could find was in oauth2-proxy, but upstream turned down the proposal: oauth2-proxy/oauth2-proxy#958 (comment)

Edit, ah I see, there's https://github.com/projectcontour/contour-authserver, which seems to have some support for OIDC.

Authorino can also be used as an Envoy authorisation server but that also needs the OAuth filter to ensure that the request has the bearer token before the authorisation call.

@youngnick Happy to help review or test once you have a design.

[carlin-q-scott]

I wonder Contour would consider copying what Istio.io did by providing an EnvoyFilter CRD that allows us to use any of the envoy http filters with the gateway proxy. Here's an example of using it with the oauth2 filter: https://szczeles.github.io/OAuth2-based-authentication-on-Istio-powered-Kubernetes-clusters/

Envoy Proxy is working on their own Gateway implementation with support for the OAuth2 filter, but they're implementing it as an Oauth CRD instead. I prefer Istio's approach because it allows us to define whatever we want.

[rshiva777]

Could any one please let me know when would be the oauth2 integration for contour will get released?

[davidgiga1993]

This would be really great! It's currently one of the blocking points to rollout contour. Is there any work item that one could start working on? Or is the general architecture still pending?

[skriss]

This would be really great! It's currently one of the blocking points to rollout contour. Is there any work item that one could start working on? Or is the general architecture still pending?

@davidgiga1993 this is still in need of a design in order to move forward. If you're interested in working on that, let us know. You can see other design docs here.

[lsjostro]

Mean while we have created an ext authz extension that does exactly this. Heavily inspired of istio authserver with additional features like pre/post auth OPA rego policies, and encryption. It's a bit early days and lacks documentation. But we run it in prod already at a few places. Happy to receive feeback! https://github.com/shelmangroup/envoy-oidc-authserver

[rgarrigue]

@lsjostro wouldn't mind trying it out somewhen, mind providing a working example with Contour ?

[lsjostro]

@lsjostro wouldn't mind trying it out somewhen, mind providing a working example with Contour ?

Thanks for the interest @rgarrigue! 😄
Yes, I will priorities getting some documentation in place.

but basically it's implemented as a Envoy External Authz extension. So following this guide https://projectcontour.io/guides/external-authorization/. An example k8s deployment of oidc-authserver can be found here https://github.com/shelmangroup/envoy-oidc-authserver/tree/main/run/k8s/manifests

The configuration for the OIDC providers looks like this https://github.com/shelmangroup/envoy-oidc-authserver/blob/main/run/k8s/manifests/oidc-providers.yaml .. uses header match to match against a provider config. This is usually the :authority header a.k.a virtualhost.fqdn in the HTTPProxy resource.

example HTTProxy resource:

apiVersion: projectcontour.io/v1alpha1
kind: ExtensionService
metadata:
  name: oidc-authserver
spec:
  protocol: h2c
  services:
    - name: oidc-authserver
      port: 8080
  timeoutPolicy:
    response: 1500ms
---
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: podinfo
spec:
  virtualhost:
    fqdn: podinfo.my-fancy-domain.com
    tls:
      secretName: contour/tls-my-fancy-domain-com
    authorization:
      extensionRef:
        name: oidc-authserver
        namespace: <namespace where oidc-authserver is deployed>
  routes:
    - services:
        - name: podinfo
          port: 9898

Example post auth trace:

[sunjayBhatia]

@lsjostro if you're interested in contributing some documentation to Contour's website, adding this project as an option to the "ecosystem" page here: https://projectcontour.io/resources/ecosystem/ and/or the external auth page would be great!

[lsjostro]

@sunjayBhatia sounds like a good plan! would it make sense to replace the current example you have there?

[sunjayBhatia]

@sunjayBhatia sounds like a good plan! would it make sense to replace the current example you have there?

an addition as another option would be great!