-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for configmap of headers for auth-url per ingress #4550
Add support for configmap of headers for auth-url per ingress #4550
Conversation
Welcome @actgardner! |
Hi @actgardner. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
0d74783
to
bd8d4f5
Compare
/ok-to-test |
Codecov Report
@@ Coverage Diff @@
## master #4550 +/- ##
=========================================
Coverage ? 58.56%
=========================================
Files ? 88
Lines ? 6736
Branches ? 0
=========================================
Hits ? 3945
Misses ? 2356
Partials ? 435
Continue to review full report at Codecov.
|
8630bde
to
5833c5d
Compare
Please also add e2e test in https://github.com/kubernetes/ingress-nginx/blob/master/test/e2e/annotations/auth.go to assert the behaviour. |
a71b1ff
to
66a2bda
Compare
2963175
to
3a3eac3
Compare
@actgardner two things, first, squash the commits and you can test this locally running |
97e51e6
to
dd4db29
Compare
test/e2e/annotations/auth.go
Outdated
|
||
annotations := map[string]string{ | ||
"nginx.ingress.kubernetes.io/auth-url": "http://foo.bar/basic-auth/user/password", | ||
"nginx.ingress.kubernetes.io/auth-proxy-set-headers": "auth-headers", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ElvinEfendi @aledbf This e2e test isn't working - it doesn't seem to be adding the external auth section to the nginx config at all. I've poked around the e2e framework and I'm not sure why this is failing but the snippet tests above succeed? Is there something obvious I'm missing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure auth-headers
configmap gets created? Can you assert the existence of it here? Also why do you not create it programmatically like we do in other e2e tests. When you create it dynamically you can also assert behaviour when auth-proxy-set-headers
is configured but configmap does not exist.
dd4db29
to
7e1574c
Compare
@@ -529,44 +529,39 @@ func New( | |||
AddFunc: func(obj interface{}) { | |||
cm := obj.(*corev1.ConfigMap) | |||
key := k8s.MetaNamespaceKey(cm) | |||
// updates to configuration configmaps can trigger an update | |||
if key == configmap || key == tcp || key == udp { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ElvinEfendi These were the issue - the Store only notified the ingress of updates to a small set of ConfigMaps that are specified using flags when the controller is started (the global, tcp and udp ConfigMaps).
This fixes my issue (the end-to-end tests pass now), but I'm worried about the impact of this change on a noisy cluster (one where there's a lot of ConfigMap changes)? It would definitely have some performance impact. It seems like the alternative would be to rearchitect how the Store works so it supports a whitelist that can be updated on the fly, which is a big and fairly complex, risky change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@actgardner yes, we restrict when to update to avoid too many invocations to Sync(), which could not trigger any change in nginx but increase the CPU and memory utilization
I have a POC to only listen to one object at the time https://gist.github.com/aledbf/030f90fd8fe087048782fe8d0cfd9ce2 but I never finished the integration. With this approach, we can just watch those configmaps we really use and not everything
/retest |
@actgardner any chance you can address the comments before next Friday? |
@aledbf I can try to address the feedback before Friday, it's going to conflict with this PR though? #4586 What's the actual desired end-state here?
Should I rearchitect this to maintain a whitelist of all the headers configmaps? The change in #4586 also seems like it's going to call Sync on every configmap update? |
No, we will call the sync only if the configmap is referenced by an annotation |
You should just rebase the PR, removing the changes in store.go |
7e1574c
to
89d59e4
Compare
@actgardner You can rebase now. Also, please squash the commits |
6f02a17
to
786a3b6
Compare
/approve |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: actgardner, aledbf, ElvinEfendi The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@actgardner thank you and apologies for the delay |
What this PR does / why we need it:
Adds a new annotation
nginx.ingress.kubernetes.io/auth-proxy-set-headers
which specifies a ConfigMap ofheader: value
which are passed to an external authentication service whennginx.ingress.kubernetes.io/auth-url
is set.This is valuable to reduce the use of snippets to set headers for each ingress. The ingress validates that the keys and values will produce a valid nginx configuration.