-
Notifications
You must be signed in to change notification settings - Fork 482
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: GEP-1494 #3293
base: main
Are you sure you want to change the base?
doc: GEP-1494 #3293
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,59 @@ | ||
# GEP-1494: Auth in Gateway API | ||
|
||
* Issue: [#1494](https://github.com/kubernetes-sigs/gateway-api/issues/1494) | ||
* Status: Provisional | ||
|
||
(See status definitions [here](/geps/overview/#gep-states).) | ||
|
||
## TLDR | ||
|
||
Allow authentication works as a policy that can be attached to both the Gateway and HTTPRoute. | ||
|
||
## Goals | ||
|
||
1). In the default policy, it can add an ExtensionFilter that specifies the auth so that Gateway can be attached to. | ||
2). Individual HTTPRoutes can choose to opt out by specifying an empty extension, or a null extension. | ||
3). It can also have disabled authentication. | ||
Comment on lines
+14
to
+16
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Again, I think it's important to focus on the user story rather than details. The thing that users (well, HTTPRoute owners) want to be able to do is to ask their Gateway API implementation to ensure that requests matching some pattern (such as a path like So I think that we need a very high-level definition of that goal in here as the first item. I think the second point is a really good one - that HTTPRoute owners must also be able to require that certain route rules do not require authentication. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think opting out (at the level of HTTPRoutes) on a config otherwise enforced as a default (set at the level of the Gateway) is a need that extrapolates the auth domain, but rather a pattern that we may see at any kind of hierarchical config. I would dedicate some careful thought on this, possibly out of the scope of this GEP. Prior art: Kuadrant specifies the concept of Unsetting for its AuthPolicy and RateLimitPolicy kinds. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
My proposal is to implement one of the following options for authentication (AuthN): a default policy, an override policy, or a disabled policy. I want to keep it simple, but I’m wondering if I should consider making it more complex... |
||
|
||
|
||
## Non-Goals | ||
|
||
1). How authentication is implemented. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that the implementation of the authentication will eventually be required in this GEP, so it isn't really correct to put this in here. Maybe, let's add a |
||
2). No authorization is required in this GEP. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder if this goal isn't leaking some current approaches of separating authentication and authorisation into completely sets of configuration. This is not necessarily a bad practice but tends to lead to additional requirements on how to export and data (typically user info) from one layer to the other. After all, there's only so much use case for authorisation completely disconnected from authentication. I can see this separation eventually bumping into requests for defining, e.g., a At the very least, it open room for discussing sequencing/dependencies in the enforcement of different configs. I would recommend checking out Kuadrant's AuthPolicy and Envoy Gateway's SecurityPolicy as a references (prior art). Both see auth as a rather unified domain, I reckon. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes. I think that authentication and authorization are generally regarded as separate entities across various domains. I personally would want to see such seperation. This separation allows security teams to do better control and enforcement over ACL services in authorization, such as implementing a least privilege policy. However, I do realise that this approach may introduce an additional layer of complexity, but I think at the current stage, we are more than just to talk different possiblities than to think of implement these. |
||
|
||
## Introduction | ||
|
||
The Gateway API aims to establish a centralized authentication framework that impacts both the Gateway and HTTPRoute. This solution is designed to achieve the following objectives: | ||
|
||
1). The Gateway API should support multiple authentication methods, including Multi-Platform Authentication, traditional Authentication, and no authentication at all. Multi-Platform Authentication includes Single Sign-On (SSO), OAuth, JWT tokens, and more, while traditional Authentication involves the use of usernames and passwords. | ||
|
||
2). The authentication policy attachment mechanism should work at both the Gateway and HTTPRoute levels. The following conditions are considered: | ||
|
||
- Inherited Policy attachment: attach the Policy to a Gateway and default auth settings (but still allow them to be overridden by individual HTTPRoutes) | ||
- Direct Policy attachment: attach the Policy to a Gateway and override auth settings (which will prevent them being changed on individual HTTPRoutes) | ||
- Not have a Policy at all and just set the settings on individual HTTPRoutes | ||
Comment on lines
+26
to
+34
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a really great start and definitely information we need to consider, but I think that we again need to go a bit higher-level for this Introduction section. What this section is about is giving someone looking at this GEP some reasons why we are adding this feature. What do users want and why is it important that it's handled in Gateway API? (For this case, it's something like "it's really useful to be able to take having to worry about authentication off application developer's todo lists, and handle it correctly for them with a minimum of provided config"). Then, the other really important part is to work through what the state of the area looks like, reviewing both data planes (proxies) and what Implementation Specific things Gateway API implementations are doing in this area. |
||
|
||
|
||
## API | ||
|
||
(... details, can point to PR with changes) | ||
|
||
## Conformance Details | ||
|
||
(This section describes the names to be used for the feature or | ||
features in conformance tests and profiles. | ||
|
||
These should be `CamelCase` names that specify the feature as | ||
precisely as possible, and are particularly important for | ||
Extended features, since they may be surfaced to users.) | ||
|
||
## Alternatives | ||
|
||
(List other design alternatives and why we did not go in that | ||
direction) | ||
|
||
## References | ||
|
||
(Add any additional document links. Again, we should try to avoid | ||
too much content not in version control to avoid broken links) | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,39 @@ | ||
apiVersion: internal.gateway.networking.k8s.io/v1alpha1 | ||
kind: GEPDetails | ||
number: 1494 | ||
name: Auth in Gateway API | ||
status: Provisional | ||
# Any authors who contribute to the GEP in any way should be listed here using | ||
# their Github handle. | ||
authors: | ||
- bowei | ||
- robscott | ||
- youngnick | ||
- dprotaso | ||
- jgao1025 | ||
- justinsb | ||
- shaneutt | ||
relationships: | ||
# obsoletes indicates that a GEP makes the linked GEP obsolete, and completely | ||
# replaces that GEP. The obsoleted GEP MUST have its obsoletedBy field | ||
# set back to this GEP, and MUST be moved to Declined. | ||
obsoletes: {} | ||
obsoletedBy: {} | ||
# extends indicates that a GEP extends the linkned GEP, adding more detail | ||
# or additional implementation. The extended GEP MUST have its extendedBy | ||
# field set back to this GEP. | ||
extends: {} | ||
extendedBy: {} | ||
# seeAlso indicates other GEPs that are relevant in some way without being | ||
# covered by an existing relationship. | ||
seeAlso: {} | ||
# references is a list of hyperlinks to relevant external references. | ||
# It's intended to be used for storing Github discussions, Google docs, etc. | ||
references: {} | ||
# featureNames is a list of the feature names introduced by the GEP, if there | ||
# are any. This will allow us to track which feature was introduced by which GEP. | ||
featureNames: {} | ||
# changelog is a list of hyperlinks to PRs that make changes to the GEP, in | ||
# ascending date order. | ||
changelog: {} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although most of the discussion to date has been about a Policy object, I think that we should leave the method open until we get to the design phase, so we need to try and phrase this more like a user journey or story.
Maybe something more like "Provide a method for configuring Gateway API implementaions to add Authentication for north-south traffic. The method may also include Authorization config if practical".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Nick, thanks for your insightful comments! I initially viewed this document as a reference for developers to implement the code, but now it seems more aligned with the storytelling phase. Could you clarify which stage you're referring to as the 'design phase' and the current stage in the GEPs process document [1]?
[1]. https://gateway-api.sigs.k8s.io/geps/overview/#process
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, great point, maybe we haven't explained this very well in that doc. The design phase I'm referring to there is the phase between Provisional and Implementable - when we actually design the API to be used and have it ready for implementations to do the work to actually implement it (which is the Implementable state).
The aim of the Provisional state is to outline the what, who, and why, along with any relevant background information. This is somewhat similar to the story generation phase of Agile development, but with a slightly larger scope (because we need to record the background as well).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay. Got it. Does this GEP also include the gRPC protocol? I will revise this to read "Provide a method for configuring Gateway API implementaions to add HTTP Authentication for north-south traffic. The method may also include Authorization config if practical". Does it sound good?