nginx-ingress-controller: support for oauth2_proxy

[colemickens]

I'd like to have an nginx-ingress-controller that that works with https://github.com/bitly/oauth2_proxy,

It looks like this will require more than surface level changes to nginx-ingress-controller. I'm curious if this is something that is worth accommodating in this "upstream" nginx-ingress-controller or if it would be invasive enough to not be desired?

I'm just starting to look into this but it seems like it would requiring:

• augmenting the nginx template to accept other chunks of config for configuring oauth2_proxy
• alternatively, modifying it to optionally accept another ConfigMap that contains the nginx template so users could do arbitrary other config changes while still benefiting from the rest of the nginx-ingress-controller machinery
• needs to consume a Secret to set relevant env vars or flags for oauth2_proxy (the oauth client_secret)

The idea here is to be able to deploy Ingress along with kube-lego (for SSL to protect auth info/cookies) and then have oauth2_proxy configured to accept users for a certain Azure Active Directory tenant or to a GitHub organization so that I can automatically give my coworkers access to cluster service while keeping others out.

I suppose this could also be done as an extra hop, with another nginx with oauth2_proxy sitting infront of the ingress nginx Pods but that seems a bit less clean.

I'm curious if anyone else is interested in this, and if it makes sense to be part of the upstream nginx-ingress-controller or if its more appropriate as a separate project?

[aledbf]

alternatively, modifying it to optionally accept another ConfigMap that contains the nginx template so users could do arbitrary other config changes while still benefiting from the rest of the nginx-ingress-controller machinery

This is possible now. Check the custom-nginx-template section

[aledbf]

@colemickens this is similar to this request #1327

[aledbf]

@colemickens what if instead of adding this code inside the controller we use auth_request to delegate the authentication to an external service/url?

[colemickens]

That's a good point. If oauth2_proxy runs as a normal Service/Deployment then we would just need a way to configure auth_request to point to the oauth2_proxy Service. That seems remarkably straight forward actually.

[aledbf]

need a way to configure auth_request to point to the oauth2_proxy Service

What about a global configuration and an annotation like ipwhitelist?
This allows the semantic "all the services require authentication" and/or "this ingress requires authentication" (the annotation overrides the global value, to allow a different auth service)

[colemickens]

I took a look at the ipwhitelist and I understand how I could implement a similar annotation for the auth_request field. I would like to take a crack at this tonight or in the next few days.

However, I'm not sure I understood this portion:

This allows the semantic "all the services require authentication" and/or "this ingress requires authentication" (the annotation overrides the global value, to allow a different auth service)

Are you saying that I could read the annotations off of the Ingress object for the global nginx config and could then read annotations from the individual services to allow auth to be applied to only a portion of the Ingress (and/or to override the global nginx config)?

[aledbf]

However, I'm not sure I understood this portion:

Sorry about that.
You can add a global option like WhitelistSourceRange and an annotation in the Ingress rules.
This allows authentication to all the ingress rules in the controller or just in the ingress with the annotation (the annotation always overrides the global value).

[aledbf]

@colemickens just in case a couple of day I started with this here
After merging my pending PRs my plan is to continue with this

[colemickens]

Thinking about picking this up again. Looks like you copied the directory of one of the other extension/annotations and started adding in the annotations for auth_request. Can you give me a brief rundown on the 4 annotations and how they differ so I can continue on the same path you were headed down?

[aledbf]

@colemickens tomorrow this will be working (1796)

Can you give me a brief rundown on the 4 annotations...

Only the annotation ingress.kubernetes.io/auth-url is required

[colemickens]

Oh wow, cool, thank you!

[rtluckie]

@colemickens were you able to get nginx-ingress-controller + oauth2_proxy working w/ the ingress.kubernetes.io/auth-url annotation? If so, could you post a gist of your ingress def?

[kop]

@rtluckie, how did you tried this? I'm sitting here waiting for 0.8.4 release, though it will be included only there :)

[kop]

@aledbf, is there a chance to see this released anytime soon?

[enzian]

@colemickens : What values did you provide to interact with oauth2_proxy? Do you have samples of the deployments/services of oauth2_proxy and how it's references in the ingress resource?

[colemickens]

I'm sorry, I never got this into a complete/documented state.

[colemickens]

To be honest, I don't know if there was an updated container published, per @kop's question.

[mizzao]

I've been trying to follow the example here but am not getting any redirect to oauth2_proxy. If anyone has a working example, I'd love to see it!

[colemickens]

I don't run in this configuration anymore. Further, this is sort of a tease. As soon as you get this setup working, you realize you want to be able to control authz for different users lists for different services, etc.

I think there's a place for a small project that probably doesn't re-use oauth2proxy (I found a lot of problems with it when trying to get some of this stuff working... there's a reason the example uses my build of oauth2proxy) that allows for configuring access per-Ingress object and doesn't require users to manually manage such fragile annotations.

However, this isn't something I have time or attention for, nor really trying to run through this oauth2proxy example again.

[halkeye]

This is a fairly old topic, but https://hub.docker.com/r/lassoproject/lasso/ is one that uses the nginx auth apis.

This allows you to have access to the username/email in nginx, then do an your normal limit commands in there.

It also totally allows it to be proxied to the backend as a header (which was nice for grafana)