Skip to content

Conversation

@shaun-nx
Copy link
Contributor

@shaun-nx shaun-nx commented Dec 9, 2025

Proposed changes

This change updates the AuthenticationFilter proposal.

Changes made:

  • Update API validation
  • Removal of OnFailure configuration
  • Add additional details on functional testing

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.

  • I have read the CONTRIBUTING doc
  • I have added tests that prove my fix is effective or that my feature works
  • I have checked that all unit tests pass after adding my changes
  • I have updated necessary documentation
  • I have rebased my branch onto main
  • I will ensure my PR is targeting the main branch and pulling from my branch from my own fork

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.


@github-actions github-actions bot added the documentation Improvements or additions to documentation label Dec 9, 2025
@codecov
Copy link

codecov bot commented Dec 9, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.22%. Comparing base (89aee48) to head (bb91ce1).
⚠️ Report is 5 commits behind head on main.

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.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@shaun-nx shaun-nx requested a review from tataruty December 9, 2025 15:29
@shaun-nx shaun-nx requested a review from Copilot December 9, 2025 17:35
Copy link

Copilot AI left a 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.

@shaun-nx shaun-nx requested a review from Copilot December 9, 2025 18:23
Copy link

Copilot AI left a 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.
Copy link
Contributor

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

Copy link
Collaborator

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.

Copy link

Copilot AI left a 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
Copy link
Contributor

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

Copy link
Contributor Author

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?

Copy link
Contributor Author

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.

Copy link
Contributor

@salonichf5 salonichf5 left a 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`
Copy link
Collaborator

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>

Copy link
Contributor Author

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!

Copy link
Contributor Author

@shaun-nx shaun-nx Dec 16, 2025

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>

Copy link
Contributor Author

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`
Copy link
Collaborator

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.

Comment on lines 841 to 842
- An AuthenticationFilter deployed with an empty `Realm` value
- An AuthenticationFilter deployed with an empty `secretRef.Name` value
Copy link
Collaborator

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.
Copy link
Collaborator

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
Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation

Projects

Status: 🆕 New

Development

Successfully merging this pull request may close these issues.

Update AuthenticationFilter proposal

5 participants