-
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
Adds strict match annotation + updated tests/docs #8582
base: main
Are you sure you want to change the base?
Conversation
Hi @chrisshino. 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. |
#8434 In this pull request James mentions a few things that would improve this annotation and I implemented them.
|
@@ -28,7 +28,8 @@ You can add these Kubernetes annotations to specific Ingress objects to customiz | |||
|[nginx.ingress.kubernetes.io/auth-tls-verify-client](#client-certificate-authentication)|string| | |||
|[nginx.ingress.kubernetes.io/auth-tls-error-page](#client-certificate-authentication)|string| | |||
|[nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream](#client-certificate-authentication)|"true" or "false"| | |||
|[nginx.ingress.kubernetes.io/auth-tls-match-cn](#client-certificate-authentication)|string| |
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.
let's not deprecate an annotation. Instead, the old behavior should be called this way, and the new one can have a new name
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.
makes sense! I will keep the original one here as the regex version, and then only add a new one for the strict mode!
go.mod
Outdated
@@ -15,7 +15,7 @@ require ( | |||
github.com/mitchellh/mapstructure v1.5.0 | |||
github.com/moul/pb v0.0.0-20180404114147-54bdd96e6a52 | |||
github.com/ncabatoff/process-exporter v0.7.10 | |||
github.com/onsi/ginkgo v1.16.5 | |||
github.com/onsi/ginkgo v1.16.4 |
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.
why is this being downgraded?
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.
these must have happened after I did a go mod tidy, im not sure why Ill make sure they are the same as before!
go.mod
Outdated
@@ -40,7 +40,7 @@ require ( | |||
k8s.io/component-base v0.23.6 | |||
k8s.io/klog/v2 v2.60.1 | |||
pault.ag/go/sniff v0.0.0-20200207005214-cf7e4d167732 | |||
sigs.k8s.io/controller-runtime v0.11.2 | |||
sigs.k8s.io/controller-runtime v0.10.3 |
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.
why is this being downgraded?
if u.ExactMatchCN != "hello-app" { | ||
t.Errorf("expected %v but got %v", "hello-app", u.ExactMatchCN) | ||
} | ||
if match, _ := regexp.MatchString(u.RegexMatchCN, "hello"); !match { |
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.
please don't ignore the error here
config.MatchCN, err = parser.GetStringAnnotation("auth-tls-match-cn", ing) | ||
if err != nil || !commonNameRegex.MatchString(config.MatchCN) { | ||
config.MatchCN = "" | ||
config.ExactMatchCN, err = parser.GetStringAnnotation("auth-tls-exact-match-cn", ing) |
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.
Is there any priority here? Like exact > regex? If so, we should early exit if there's an exact match, otherwise try the regex.
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.
since they are essentially 2 different annotations there isn't necessarily a priority.
config.ExactMatchCN = "" | ||
} | ||
|
||
config.RegexMatchCN, err = parser.GetStringAnnotation("auth-tls-regex-match-cn", ing) |
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.
I want actually that we validate if this is a valid regex per NGINX and not just add it to nginx.conf.
Based on the feedbacks, do we have a common pattern of required strings, like " REGEX = domain.*" or something like that, in a way we can sanitize/remove possible dangerous characters?
If so, let's do this (in both fields actually, we should validate what character set is allowed here)
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.
hmm yea we can do this, I think it will always something like domain.*, but for example say the person wanted to use a regex match and the CN was = "my.example.com" and their regex only contained "example", would it fail because it doesn't have a dot after?
Or what if the domain contains numbers? Any suggestions on what a good pattern could look like here? probably something that contains letters, numbers or dots, but no other characters (for example, brackets "<", ">" ?
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.
@rikatz thank you for the thorough review 🙏 , I believe this should address your comments |
hmm so whenever the e2e test runs, the go mod is switching those 2 dependency that you called out above to the lower versions? Then it is failing, not sure why? |
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.
/triage accepted
/priority backlog
/kind bug |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
@chrisshino 👋 long time no see, sorry! Thank you!!! |
/lifecycle active |
520d69b
to
c88afeb
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: chrisshino The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/assign @rikatz |
@rikatz okay so it looks like in all the back and forth I had made a git mistake and pushed the wrong thing, I have since updated that and pushed all my actual fixes that addressed your issues! For some reason my CLA is still failing because of a commit message? I dont want to mess with git anymore than I have already lol do you know a good way of fixing this? Then this PR should be good to go! Thanks again and sorry it took so long |
ah yeah, the joys of git :D been there, had the same problem as you, so let's map them:
To rebase:
Helps? :D Otherwise, we can see what to do. |
c88afeb
to
2c0f3f7
Compare
@rikatz wow thanks for the step by step instructions!! Looks like everything should be good now, its just running through CI stuff but I have the correct tags now |
PR needs rebase. 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. |
@chrisshino @rikatz Long story short: the combination of using ACME (e.g. letsencrypt) to issue a server cert + using client auth certs on ingress-nginx together with nginx.ingress.kubernetes.io/server-snippet: |
set $CERT_CHECK "";
if ($scheme = https) {
set $CERT_CHECK "HTTPS";
}
if ($ssl_client_s_dn !~ "CN=my-cn") {
set $CERT_CHECK "${CERT_CHECK}_NOCNMATCH";
}
if ($CERT_CHECK = HTTPS_NOCNMATCH) {
return 403 "client certificate unauthorized: $ssl_client_s_dn\n";
} In my view, the check using the |
What this PR does / why we need it:
This officially closes: #8330, this patch is needed to satisfy some of the feedbacks received on the original branch that was already merged in.
Types of changes
Which issue/s this PR fixes
How Has This Been Tested?
Checklist: