Enhancement Proposal: Authentication Filter

[shaun-nx]

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.

• 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.

NONE

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.95%. Comparing base (3305254) to head (f71701a).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4136      +/-   ##
==========================================
- Coverage   85.97%   85.95%   -0.02%     
==========================================
  Files         131      131              
  Lines       14063    14063              
  Branches       35       35              
==========================================
- Hits        12090    12088       -2     
- Misses       1772     1773       +1     
- Partials      201      202       +1     

☔ 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.

[tataruty]

why do you call it htpasswd? it a bit confuses me since below there is a reference:

            auth_basic_user_file /etc/nginx/secrets/basic-auth-users/htpasswd;

[shaun-nx]

So in this case, htpasswd is the key that we use to access to user's data stored in basic-auth-users

That secret might look like this:

apiVersion: v1
kind: Secret
metadata:
  name: basic-auth-users
type: Opaque
stringData:
  htpasswd: |
    admin:$apr1$ZxY12345$abcdefghijklmnopqrstuvwx/
    user:$apr1$AbC98765$mnopqrstuvwxyzabcdefghiJKL/

This is mostly just an example name. You can use anything for that key.

[sjberman]

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.

[sjberman]

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.

[sjberman]

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.

[sjberman]

Maybe worth talking to the Gateway API community members around the intentions of the API in supporting native versus external auth.

[ciarams87]

We should remove the image from this PR too

[ciarams87]

Suggested change

	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.

[ciarams87]

Suggested change

	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.

[ciarams87]

Suggested change

	- Design a means of configuring authenticaiton for NGF
	- Design a means of configuring authentication for NGF

[ciarams87]

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.

@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).