-
Notifications
You must be signed in to change notification settings - Fork 504
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
Add Gateway to core reference from kinds #1223
Conversation
Hi @rainest. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: rainest 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 |
/ok-to-test |
Add Gateway to the list of core kinds implementations must support in ReferenceGrantFrom. Gateway Listener core support requires implementations support references to TLS Secrets in other namespaces, and these references require permission from a ReferenceGrant in the target namespace.
51df76c
to
d6cca04
Compare
I thought this looked familiar... I think this is roughly the same as #1181, and my comment there applies here. |
Closed in favor of 1181. |
What type of PR is this?
/kind documentation
/kind api-change
What this PR does / why we need it:
Adds Gateway to the list of kinds ReferenceGrantFrom must support for core support
https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.SecretObjectReference states:
This indicates cross-namespace SecretObjectReferences are required for core support. This doesn't clarify how you should check their validity, though a Gateway ReferenceGrantFrom entry appears correct, as it's the only independent type that can include a SecretObjectReference (via Listener->GatewayTLSConfig). By extension, it appears you must support Gateways in addition to the currently listed Route types.
Does this PR introduce a user-facing change?:
Maybe? This seems like it was already implied, but just omitted from docs, and this is more a clarification point to say "yes, you should check for a Gateway from rule, not a GatewayTLSConfig from rule". I'm ambivalent as to whether this should instead be: