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
Factor-out metrics related logic from authentication logic. #87631
Factor-out metrics related logic from authentication logic. #87631
Conversation
Reducing the diff of #85113 |
/assign @timstclair |
/assign @logicalhan |
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.
Thanks for breaking this out into a separate PR.
// Anything else (custom service accounts, custom external identities, etc.) | ||
default: | ||
return "other" | ||
func audiencesIntersect(apiAuds, responseAudiences authenticator.Audiences) bool { |
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.
/cc @mikedanese
To double check security critical 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.
I agree this preserves the existing logic, but the method name is fairly misleading, since it short-circuits on empty parameters. Consider renaming to audiencesAreAcceptable() or something similar.
As a follow-up, given that (I think) we are now wrapping all audience-agnostic authenticators in ones that know how to return the API server audience in the response, I think we should probably drop the len(responseAudiences) == 0
short-circuit.
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.
Renamed to audiencesAreAcceptable.
Will follow-up with a PR to remove the len(responseAudiences) == 0
short-circuit.
staging/src/k8s.io/apiserver/pkg/endpoints/filters/metrics_test.go
Outdated
Show resolved
Hide resolved
38d1ef6
to
ad5c741
Compare
ad5c741
to
ca61066
Compare
/lgtm |
/test pull-kubernetes-kubemark-e2e-gce-big |
/assign @liggitt |
/test pull-kubernetes-e2e-gce-100-performance |
successLabel = "success" | ||
failureLabel = "failure" | ||
errorLabel = "error" | ||
audiencesDoNotIntersectLabel = "non-intersecting-audiences" |
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 a result?
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.
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.
Shouldn't we report it as an error and not as a new result type? This is a pretty old metric, so I don't want to break the semantics even if it's alpha. On top of that, "success"/"failure"/"error" seems like a reasonable breakdown for results and I'm not sure that "non-intersecting-audiences" is distinct enough from "error" to warrant introduction of another state.
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.
Done - now classifying non-intersecting audiences as a failure.
1ef51cf
to
c9aa603
Compare
c9aa603
to
9562ee8
Compare
Verify failure looks real. |
9562ee8
to
a689048
Compare
/test pull-kubernetes-node-e2e-containerd |
/lgtm |
Hello @RainbowMango |
/milestone v1.18 |
@jtslear Seems @mikedanese want @LiGgit take a look. |
a couple comments on method name and logging, one follow-up requested, lgtm otherwise |
a689048
to
c0bad80
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: immutableT, liggitt, mikedanese 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 |
/retest |
Looks like this is good to go. |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Improve readability of the filters/authenticator package by extracting metrics' related logic into a separate file.
Cover metrics' related logic by unit tests.
Does this PR introduce a user-facing change?: