-
Notifications
You must be signed in to change notification settings - Fork 486
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
Implementing policy attachment GEP #736
Implementing policy attachment GEP #736
Conversation
Adding a hold to follow up with #732 (comment). |
/hold |
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.
This is looking great, just a few small wording changes from me.
dd8737b
to
f25c417
Compare
bf74cbe
to
b145f5c
Compare
Thanks for the great feedback on this @hbagdi and @youngnick! I think I've responded to all feedback now, PTAL. |
b145f5c
to
4f56cfe
Compare
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.
nits and questions, this LGTM.
// Namespace is the namespace of the referent. When unspecified, the local | ||
// namespace is inferred. Even when policy targets a resource in a different | ||
// namespace, it MUST only apply to traffic originating from the same | ||
// namespace as the policy. |
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.
So, let's say we have gateway-a in gateway-ns namespace and route-b in route-ns namespace.
If I've a policy that in gateway-ns that targets a route-b and I also have a policy in route-ns that targets route-b, the hierarchy is policy in gateway-ns > policy in route-ns.
Is that right?
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.
Yes, that's my interpretation, but you've got me thinking that we may want to add more restrictions around cross-namespace policy attachment. I think the primary use case was for a mesh implementation to be able to apply policy to requests originating from the local namespace to a given destination. There's clearly also use cases for Gateway as you described above, but they may become messier than intended and/or be difficult for an implementation to support. I was about to suggest that we should make this an "Extended" concept, but the whole idea of policy attachment is already extended. So that's a long way of saying that I think your interpretation is correct, but we probably need to communicate that implementations can choose to not support cross-namespace policy.
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.
but we probably need to communicate that implementations can choose to not support cross-namespace policy.
Since we are not sure, I recommend keeping cross-namespace policy for gateway out of scope. There is a need for sure but punting on would be for the best. There are a lot of other features here and we shouldn't feel pressured.
/lgtm |
4f56cfe
to
ed15276
Compare
/hold cancel |
ed15276
to
fa70c18
Compare
* The oldest Policy based on creation timestamp. For example, a Policy with a | ||
creation timestamp of "2021-07-15 01:02:03" is given precedence over a Policy | ||
with a creation timestamp of "2021-07-15 01:02:04". | ||
* The Policy appearing first in alphabetical order by "<namespace>/<name>". For |
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.
nit: during a conflict namespace should always be the same, right? due to the hierarchy.
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.
I think that's likely true, but I'd prefer to avoid any possibility of conflict here if any form of hierarchy changes in the future. This is the same guidance we've used for other conflict resolution throughout the API, so I think it makes sense to keep it the same.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: howardjohn, robscott 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:
Approvers can indicate their approval by writing |
Thanks for the great feedback on this one! I think I've addressed everything now, PTAL. |
/lgtm |
What type of PR is this?
/kind documentation
/kind feature
What this PR does / why we need it:
This adds documentation for the policy attachment pattern described in GEP #713 and adds the associated
PolicyTargetReference
type. When combined with #732, this should be all that's required to implement the GEP.Does this PR introduce a user-facing change?:
Deploy Preview: https://deploy-preview-736--kubernetes-sigs-gateway-api.netlify.app/v1alpha2/references/policy-attachment/