Validation: remove CEL for PolicyTargetRef to allow vendor extensions #3414
Conversation
…api GatewayClass Signed-off-by: Ian Rudie <[email protected]>
Signed-off-by: Ian Rudie <[email protected]>
Signed-off-by: Ian Rudie <[email protected]>
istio-testing
added
the
size/XS
istio-testing
added
size/S
type/v1beta1/selector.proto
Outdated
| // | ||
| // When binding to a GatewayClass resource using PolicyTargetReference, your policy must be in the root namespace. | ||
| // | ||
| // Supported kinds are core/Service, networking.istio.io/ServiceEntry, gateway.networking.k8s.io/Gateway, and gateway.networking.k8s.io/GatewayClass |
There was a problem hiding this comment.
This is documented on the individual usages. Like
networking/v1alpha3/envoy_filter.proto
871: repeated istio.type.v1beta1.PolicyTargetReference targetRefs = 6;
We should update those. We might want to only include it there, in case there are per-policy supported types? If we know all will be the same then here is probably good
There was a problem hiding this comment.
Good shout. Actually, looking at this more closely it's probably most clear now with no CEL to simply not mention supported group/kind of the PolicyTargetRef message at all. Support likely varies by where it is used and should be mentioned where this message is used going forward.
There was a problem hiding this comment.
Would we want to allow binding resources which are not Authorization Policy to a GatewayClass?
There was a problem hiding this comment.
I moved supported group/kind from being centralized on the message to being in our higher lever resources where the PolicyTargetRef is used. TBH, after the move I'm feeling less certain about doing it this way but it is an improvement over having inconsistent group/kind information in different contexts.
| - https://github.com/istio/istio/issues/54696 | ||
| releaseNotes: | ||
| - | | ||
| **Removed** CEL validation of group/kind for PolicyTargetReference to enable vendor extensions |
There was a problem hiding this comment.
If we're removing the CEL validation, should we add this to the OSS ValidatingWebhook?
There was a problem hiding this comment.
Maybe status, "you tried to bind to a beep.boop.bop.io/beepboop and Istiod has not honored this"
There was a problem hiding this comment.
Yeah that would work; just some indication since CEL isn't going to be enforcing it now
…sed in resources Signed-off-by: Ian Rudie <[email protected]>
This PR removes CEL validation from PolicyTargetRef for two primary reasons: