-
Notifications
You must be signed in to change notification settings - Fork 153
Update AuthenticationFilter proposal #4424
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
base: main
Are you sure you want to change the base?
Update AuthenticationFilter proposal #4424
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4424 +/- ##
==========================================
- Coverage 86.24% 86.22% -0.02%
==========================================
Files 132 132
Lines 14566 14566
Branches 35 35
==========================================
- Hits 12562 12560 -2
- Misses 1791 1793 +2
Partials 213 213 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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.
Pull request overview
This PR updates the AuthenticationFilter proposal by refining the API design, removing the OnFailure configuration from the main spec, and enhancing documentation quality. The changes move AuthFailure customization to stretch goals while improving clarity throughout the proposal.
Key Changes:
- Removed OnFailure configuration from BasicAuth and JWTAuth specs, relocating it to stretch goals
- Enhanced functional testing section with detailed test case scenarios
- Fixed numerous spelling and grammatical errors throughout the document
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <[email protected]>
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.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| ### Functional Test Cases | ||
|
|
||
| Note: The keyword "resolved" is used to refer to a filter that the controller has found, and matches the reference of the route rule. |
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 see invalid functional tests for authentication as Authentication failed, and Authentication passed - for valid, means we get a response from the route behind auth filter.
Don't we do this full check in functional tests?
| - Expected outcome: Requests to all route rules referencing the filter successfully process authentication requests | ||
| - Resolved filter referenced by rules in multiple HTTP/GRPCRoutes | ||
| - Expected outcome: Requests to all route rules across each HTTP/GRPCRoute successfully process authentication requests | ||
|
|
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.
With our other functional tests, we also verify that the nginx configuration is correct.
Co-authored-by: Saloni Choudhary <[email protected]>
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.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| This section covers deployment scenarios that are considered invalid | ||
|
|
||
| - Single route rule with a single path in an HTTPRoute/GRPCRoute referencing an invalid AuthenticationFilter |
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.
still cannot understand what is invalid AuthFilter. What do we expect as a result of test? Because i see it as invalid configuration, that to me should be a unit tests and not functional. And as mentioned before i expect here validation of passing/not passing auth while trying to get response
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.
The first line of this section says "This section covers deployment scenarios that are considered invalid"
So for the first test cases, we have a user deploying an HTTP/GRPCroute with a single route rule that is referencing an AuthenticationFilter that is invalid.
In this case, we don't care "how" the AuthenticationFilter that is invalid, we just case that it is invalid, and we are trying to use it. Does that make sense?
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.
The test cases should cover the expected outcomes for each one now. Let me know what you think.
salonichf5
left a comment
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 is a couple of places with typos for marked but looks good to me, approving it
| The full path will use the `name` and `key` of the secret referenced by `AuthenticationFilter` | ||
| In this case, the full path will be `/etc/nginx/secrets/basic-auth-users/htpasswd` | ||
| The full path will use the `name`, `namespace`, and `key` of the secret referenced by `AuthenticationFilter` | ||
| In this case, the full path will be `/etc/nginx/secrets/default/basic-auth-users/auth` |
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.
We use a different pattern right now for storing user secrets. For example, /etc/nginx/secrets/cert_bundle_<namespace>_<name>. I think we do something here to avoid the unnecessary nested directories. It doesn't need to be named auth, because we aren't mounting the file, we're sending it and it can be named whatever we want.
Maybe something like /etc/nginx/secrets/basic_auth_<namespace>_<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.
Ah, good to know thanks!
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.
Now that you mention it, we don't actually need to include the key in the file name either since it will be unique enough with the namespace and name.
So we can use /etc/nginx/secrets/<secret-namespace>_<secret-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.
Actually, lets include basic_auth at the start. It'll make debugging easier.
| The full path will use the `name` and `key` of the secret referenced by `AuthenticationFilter` | ||
| In this case, the full path will be `/etc/nginx/keys/jwt-keys-secure/jwks.json` | ||
| The full path will use the `name`, `namespace`, and `key` of the secret referenced by `AuthenticationFilter` | ||
| In this case, the full path will be `/etc/nginx/keys/default/jwt-keys-secure/jwks.json` |
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.
Same comment as above regarding naming.
| - An AuthenticationFilter deployed with an empty `Realm` value | ||
| - An AuthenticationFilter deployed with an empty `secretRef.Name` value |
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 don't think we verify OpenAPI schema on our other policies, so these can be skipped.
| Two or more route rules each with two or more paths in an HTTPRoute/GRPCRoute referencing an invalid AuthenticationFilter | ||
| - Expected outcomes: | ||
| Both route rules are marked as invalid. | ||
| Requets to each paths in each route rule will return a 500 error. |
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'd do a typo pass on this doc again, there are quite a few misspellings.
| Package context contains the functions for storing extra information in the gRPC context. | ||
| */ | ||
| package context //nolint:revive // ignoring conflicting package name | ||
| package context |
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.
This has been an inconsistent lint failure and I'm not sure why. We probably want a separate PR to handle this if needed, not tagged onto a doc update.
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.
Interesting, I didn't notice this file was here in the files changed.
Did the linter remove the //nolint comment? I don't remember doing this myself.
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.
Hm, it must have. That's odd.
Proposed changes
This change updates the AuthenticationFilter proposal.
Changes made:
Details related to AuthFailure are captured in the Stretch Goals section
Closes #4423
Checklist
Before creating a PR, run through this checklist and mark each as complete.
Release notes
If this PR introduces a change that affects users and needs to be mentioned in the release notes,
please add a brief note that summarizes the change.