Enhancement Proposal: Authentication Filter #4136
Conversation
github-actions bot added the documentation 
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@ ## main #4136 +/- ## ========================================== + Coverage 85.98% 85.99% +0.01% ========================================== Files 131 131 Lines 14111 14111 Branches 35 35 ========================================== + Hits 12133 12135 +2 + Misses 1774 1773 -1 + Partials 204 203 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
See the proposals README for instructions on how to build a proposal.
It starts with a provisional that just includes the goals and non-goals. If those are approved, then we write the Implementable version of the doc, which includes all of the details, per our template.
Have we confirmed the timeline of the Gateway API AuthFilter? I thought it was originally slated for 1.4, but was then pulled out, which tells me it may be closer than we think. The main thing I worry about is if it comes out sooner, we now have two separate APIs to support the same thing, and that will be a pain to reconcile.
Also, fewer CRDs = better. This is about UX, and the larger sprawl we have, the more work for a user to manage all of these configurations. We shouldn't make the UX worse in order to make our code simpler.
| Following up my previous comment, the Gateway API AuthFilter is already defined and exists in the API, it's just experimental. We've supported experimental features before (see BackendTLSPolicy, TLSRoute), so we can certainly support this one. It's obviously subject to change (and users should be aware of this), but we don't have to wait for features to be standard to start supporting them. With that in mind, we should definitely prioritize exploring that API right now to see if we can use it for basic auth in nginx, instead of rewriting the same API for ourselves. |
| Ok, maybe I need to think about this some more, because the Gateway API filter is intended for external auth. But nginx supports native auth (basic and jwt for our current use cases), which is what you're actually writing about in here. So maybe it does make sense to define our own filter for the native nginx auth. |
| Maybe worth talking to the Gateway API community members around the intentions of the API in supporting native versus external auth. |
| | ||
| ## Summary | ||
| | ||
| Design and implement a means for users of NGINX Gateway Fabric to enable authenticaiton on requests to their backend applications. |
There was a problem hiding this comment.
| Design and implement a means for users of NGINX Gateway Fabric to enable authenticaiton on requests to their backend applications. | |
| Design and implement a means for users of NGINX Gateway Fabric to enable authentication on requests to their backend applications. |
| ## Summary | ||
| | ||
| Design and implement a means for users of NGINX Gateway Fabric to enable authenticaiton on requests to their backend applications. | ||
| This new filter should eventually expose all forms of authentication avaialbe through NGINX, both Open Source and Plus. |
There was a problem hiding this comment.
| This new filter should eventually expose all forms of authentication avaialbe through NGINX, both Open Source and Plus. | |
| This new filter should eventually expose all forms of authentication available through NGINX, both Open Source and Plus. |
| | ||
| ## Goals | ||
| | ||
| - Design a means of configuring authenticaiton for NGF |
There was a problem hiding this comment.
| - Design a means of configuring authenticaiton for NGF | |
| - Design a means of configuring authentication for NGF |
@sjberman Sorry, I'm only catching up on all my PR reviews today after the release. Yes, exactly - the GWAPI filter is external auth only. There is nothing precluding us from supporting this functionality in the future in addition to a native authentication extension, if that is required at a later date. We could work with the community on defining a native auth extension, but because every dataplane exposes a&a functionality in a different way, I would see it taking a very long time to come up with something that would work for everyone, and even then, I imagine it would have to be quite limited in its use case (hence why the decision was made to go with external auth in the first place). |
| - Authentication failures return appropriate status by default (e.g., 401/403) | ||
| - Ensure response codes are configurable |
There was a problem hiding this comment.
aren't these response codes too? 401 or 403?
We could combine this into one goal related to response codes.
There was a problem hiding this comment.
Sounds good. I'll make that change
| - Authentication failures return appropriate status by default (e.g., 401/403) | ||
| - Ensure response codes are configurable | ||
| | ||
| ## Non-Goals |
There was a problem hiding this comment.
Can we make it clear here that we're not implementing the Gateway API's ExternalAuth filter with this work, we're only supporting native auth in NGINX.
There was a problem hiding this comment.
Should be updated now
Proposed changes
This document proposes a solution for enabling Authentication use cases through NGINX Gateway Fabric.
Closes #4052
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.