-
Notifications
You must be signed in to change notification settings - Fork 626
Add security considerations guide, update security model #4219
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
base: main
Are you sure you want to change the base?
Conversation
|
/hold |
c6debd0 to
cb65606
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: rikatz The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
cb65606 to
204965a
Compare
204965a to
21fcd50
Compare
robscott
left a comment
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.
Thanks @rikatz, this is great!
| ## Avoiding hostname/domain hijacking | ||
|
|
||
| Gateway controllers work to disambiguate and detect conflicts caused by sharing | ||
| different ports, protocols, etc. between various listeners. (?) |
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.
Maybe instead of focusing on listeners, focus on the overall theme that it's possible in Gateway API for different Routes or ListenerSets to both claim the same hostname + path, and that Gateway controllers are responsible for conflict resolution.
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.
Rob, I am having some bad time here to give you a proper resolution :D do you mind doing a suggestion on how this should look like (unless it is more than 1 line of change!)
| Owners of resources should be aware of the usage of [ReferenceGrants](../api-types/referencegrant.md). | ||
| This should be audited and limited by admins (needs some better writing here). | ||
|
|
||
| The intended use of ReferenceGrants is to allow for the *owner* of an object where |
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.
One concern here is that we may end up rewriting/duplicating some of the ReferenceGrant docs. I think it makes sense to keep most ReferenceGrant-specific information in those docs, and then keep this doc for suggestions on how to further limit the use of ReferenceGrant.
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.
@robscott do you think the referencegrant docs already cover enough of this?
I am adding then just a reference on the ReferenceGrant docs for the security considerations, and on this document I am removing almost all of this text, and leaving bare minimum related to security.
cc @youngnick I didn't erased your text from the original document :) so if you feel we still should add that part of ReferenceGrant here or on ReferenceGrant api-reference lmk!
|
/hold cancel |
24f83c9 to
d58d3b9
Compare
What type of PR is this?
/kind documentation
What this PR does / why we need it:
Adds a security considerations guide for Gateway API
Which issue(s) this PR fixes:
Related #3709
Does this PR introduce a user-facing change?: