Enhancement Proposal: ExternalAuthFilter

[shaun-nx]

Proposed changes

This document proposes a means to integrate with Gateway API GEP-1494.
This defines an standardized API for HTTP Authentication through communication with an External Auth Service.
This service can be an IdP such as Keycloak or AzureAD. It can also be our own deployable Auth Service based on NGINX.

Relates to #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.97%. Comparing base (5c78a60) to head (4f5a41e).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4156      +/-   ##
==========================================
- Coverage   85.99%   85.97%   -0.03%     
==========================================
  Files         131      131              
  Lines       14063    14063              
  Branches       35       35              
==========================================
- Hits        12093    12090       -3     
- Misses       1770     1772       +2     
- Partials      200      201       +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]

you haven't added the case when they can co-exist with filter option?

[sjberman]

Reminder: Provisional docs should only have the Goals and non-Goals, no design. This is described in the proposals README.

Once the goals are approved, then we add the design and update to Implementable.

[sjberman]

These would not apply to the external auth filter, because they are native NGINX capabilities. For external auth, we would use the auth_request module to call out to an external auth server (specifically referring to basic and jwt)

[sjberman]

NGINX native auth and external auth using the Gateway API are two separate features. Is the intention and requirements of the Auth epic to build both of these features, or just the former? I just want to make sure we're not adding scope that wasn't intended.

[shaun-nx]

NGINX native auth and external auth using the Gateway API are two separate features. Is the intention and requirements of the Auth epic to build both of these features, or just the former? I just want to make sure we're not adding scope that wasn't intended.

Hey Saylor.
The AuthenticationFilter: Basic Auth epic assumes we are choosing to move forward with our own AuthenticationFilter CRD and not integrate with the ExternalAuthFilter from the GatewayAPI.

To your comment on "NGINX native auth and external auth using the Gateway API are two separate features", this isn't necessarily true.

In the case of NGINX native auth, where we build out our own AuthenticationFilter, this will of course include a spec for enabling and configuring authentication like BasicAuth and JWT.

In the case of external auth using the Gateway API, while a user can choose to reference an external service that isn't using NGINX (e.g. Keycloak), one thing that's covered in this proposal is providing users with a deployable NGINX External Auth Service.

[sjberman]

The #4056 epic assumes we are choosing to move forward with our own AuthenticationFilter CRD and not integrate with the ExternalAuthFilter from the GatewayAPI.

To your comment on "NGINX native auth and external auth using the Gateway API are two separate features", this isn't necessarily true.

Auth itself could be seen as a "single feature", but as you stated in the first sentence, the epic is only intending to support our custom Auth API for native auth. So if that's all that the requirements are, then why do we need a design right now for integrating with the Gateway API external auth? That is a different scope of work.

[ciarams87]

Suggested change

	This proposal aim to provider users of the Gateway API with a native form of Authenticaiton through Gateway API's [HTTPExternalAuthFilter](https://gateway-api.sigs.k8s.io/reference/spec/#httpexternalauthfilter)
	This proposal aim to provider users of the Gateway API with a native form of Authentication through Gateway API's [HTTPExternalAuthFilter](https://gateway-api.sigs.k8s.io/reference/spec/#httpexternalauthfilter)

[ciarams87]

Suggested change

	- Allow users to configure an exteranl IdP such as Keycloak or AzureAD
	- Allow users to configure an external IdP such as Keycloak or AzureAD

[salonichf5]

Suggested change

	This proposal aim to provider users of the Gateway API with a native form of Authenticaiton through Gateway API's [HTTPExternalAuthFilter](https://gateway-api.sigs.k8s.io/reference/spec/#httpexternalauthfilter)
	This proposal aims to provide users of the Gateway API with a native form of Authenticaiton through Gateway API's [HTTPExternalAuthFilter](https://gateway-api.sigs.k8s.io/reference/spec/#httpexternalauthfilter)

[salonichf5]

layer 4 routes are also out of scope here

[shaun-nx]

The #4056 epic assumes we are choosing to move forward with our own AuthenticationFilter CRD and not integrate with the ExternalAuthFilter from the GatewayAPI.

To your comment on "NGINX native auth and external auth using the Gateway API are two separate features", this isn't necessarily true.

Auth itself could be seen as a "single feature", but as you stated in the first sentence, the epic is only intending to support our custom Auth API for native auth. So if that's all that the requirements are, then why do we need a design right now for integrating with the Gateway API external auth? That is a different scope of work.

Sorry, you are right. I could have clarified that better. The reason for making this proposal was so that we could have a conversation around weather or not we wanted to go forward with ExternalAuth over our own AuthenticationFilter.

There were several conversations around the idea that we should use the Gateway API's implementation over making our own CRDs.

I don't personally have a preference either way. I just want to make sure we're having a healthy discussion. Looking back, I realize I could have presented that differently to make that more obvious. Sorry about that 😅

[shaun-nx]

Closing this for now.
The decision was made to move forward with our own AuthenticationFilter.
This proposal will be revisited in the future as the ExternalAuth API expands.