Add security considerations guide, update security model #4219
Conversation
k8s-ci-robot
added
release-note-none
k8s-ci-robot
added
the
approved
|
/hold |
k8s-ci-robot
added
the
do-not-merge/hold
rikatz
force-pushed
the
security-guide
branch
from
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 |
k8s-ci-robot
removed
the
approved
rikatz
force-pushed
the
security-guide
branch
from
cb65606 to
204965a
Compare
rikatz
force-pushed
the
security-guide
branch
from
204965a to
21fcd50
Compare
| ## 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.
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.
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!)
| * Because the number of listeners is limited on a Gateway, the administrator should | ||
| instead rely on some validation (like ValidationAdmissionPolicy or some other mechanism) | ||
| that limits what hostnames can be used on routes of each namespaces. |
There was a problem hiding this comment.
I don't think this should be a default recommendation. Maybe "If you need more listeners than a single Gateway can support, you should consider...".
There was a problem hiding this comment.
Since this feels like the start of a new section, I think it would benefit from another subheading, maybe ### More than 64 Listeners.
There was a problem hiding this comment.
changed to:
### More than 64 listeners
Gateway resource has a limitation of 64 listener entries. If you need more than 64
listeners, you should consider allowing your users to set their hostnames directly
on the routes of each namespaces but limiting what namespace can use what hostname
by relying on a mechanism like `ValidatingAdmissionPolicy`.
In case you opt to use (the still experimental) `ListenerSet`, a similar mechanism
should also be considered to limit what hostnames a `ListenerSet` can claim.
Kept the ValidatingAdmissionPolicy on its own section to be sure people udnerstand it is an example!
| 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.
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.
@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!
3 participants
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?: