Add initial draft of Auth GEP 1494

[youngnick]

/kind gep

What this PR does / why we need it:

This is to get the conversation started around Auth* in Gateway API. Hopefully this part should not be too contentious yet, but reviews gratefully accepted.

Which issue(s) this PR fixes:

Updates #1494

[LiorLieberman]

/cc

[LiorLieberman]

Thanks for very detailed content. Left a few comments

[Ongy]

Couple comments around the auth mechanisms + suggestions for user stories.

New to k8s upstream work. Do you care about style comments? E.g. defining AuthN/AuthZ twice, or would you prefer to keep this to technical bits?

[Ongy]

While the "raw" passwords in basic auth have additional issues (long lived, impersonating human on login pages), JWT and afaik OAUTH/OIDC are not generally secure against "replay" attacks.

I.e. besides mTLS (which enforces confidentiality) all mechanisms are insecure in plaintext messages, because the authentication token can at least be re-used on other connections to gain the same level of privileges.

I think it's best to move the notion of requiring encryption for safe usage out of Basic Auth and potentially add a note here that basic auth has an additional issue with long-lived (potentially higher power) tokens being exchanged.

[youngnick]

I agree with your points here, but the intent here was to say "nobody in their right mind uses Basic Auth outside of at least an encrypted connection" (in a specifcation kind of way of course).

I'm not trying to document all of the possible issues with every one of these, just to give a very basic overview so that everyone reading this who might not have all the context can get some background.

I updated the wording here, PTAL.

[Ongy]

I do get why it's here. The suggestion is mostly there to avoid someone taking the omission on other methods as sign that they are ok in an unencrypted context, when they should still be avoided.

OTOH, this isn't a tutorial about auth. And likely not front and center and the chances to trip up someone are low enough.

[youngnick]

It's a fair point, but I'd like to keep it in mind and get the current state merged so we can start working on the API design.

[Ongy]

This might leak into the "API" phase, but I think there's 2 levels to this, which are both worth an explicit mention

• The API of the proposed implementation provides enough flexibility to integrate with an authorization mechanism and protect resources entirely in the gateway
• The API allows to inject information about the authentication result into the requests and allows backend application to make authorization decisions based on this.

[youngnick]

I agree with this point, and also that we're probably better to address this in the API phase. I'm going to leave this for now, and we'll come back to it in the next PR.

[JackMyers001]

As I understand it, the current proposal only allows for "add auth to this website, except for this route". Could this be expanded to have some kind of rule-based authentication selection/bypass mechanism? I'd love to have the ability to choose a specific authentication mechanism (or bypass auth entirely) on a per-route basis, based on multiple factors (e.g. client IP, user agent).

This would make the Gateway API an amazing Layer 7 firewall, but I'm not sure if the project wants to support these kinds of capabilities; I saw this proposal was closed partly because the feature "operated too much like a WAF/firewall".

Proposed user stories:

• As Ana the Application Developer, I'm maintaining a legacy application that doesn't have any existing authentication mechanisms. I wish to enforce SSO when a user accesses the application through a browser. However, I wish to bypass authentication when the user accesses the application through the mobile app (based on the user agent), as it can't handle the SSO flow.
• As Ana the Application Developer, I wish to be able to use different authentication mechanisms for the same route based on the context of the request. I wish to use SSO when a user accesses my API through a browser, and use JWT when using my mobile app,
• As Chihiro the Cluster Admin, I wish to block undesirable User Agents or IP ranges (spiders, scrapers etc.) from accessing any services exposed by Gateway API inside my cluster.
• As Chihiro the Cluster Admin, I wish to be able to bypass AuthN when requests come in from a trusted, controlled IP range, so external services can access APIs running on my cluster without issue

[youngnick]

I agree that all of those are interesting use cases, but I think that we need to handle the simpler (enable/disable) case first.

[robscott]

Thanks @youngnick!

[youngnick]

I've just pushed an update that addresses most comments, but feel like I should clarify again: This is by no means the final state here. This is intended just to get us started, so that we can roughly agree on the goals and terminology used. We're not aiming for final quality for these sections, I expect them to get some updates as we work on the API.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: youngnick

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [youngnick]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment