-
Notifications
You must be signed in to change notification settings - Fork 3.4k
policy/api: add more CRD validations #32814
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
Conversation
/test |
pkg/k8s/apis/cilium.io/client/crds/v2/ciliumclusterwidenetworkpolicies.yaml
Show resolved
Hide resolved
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.
LGTM. Do you think it would make sense to add something to the upgrade notes? I'm assuming this wouldn't impact existing policies after an upgrade, but if folks are using a GitOps setup and reapplying resources related to these CRDs, they may run into new validation errors that weren't caught before, right?
@learnitall not a bad idea, I'll update the release notes. Any policies caught by this would have been silently rejected before, which is arguably worse :-). |
Holding until I add the release notes. |
Copying some logic from `Sanitize()` in to CRD validations: - use the OpenAPI `cidr` format directly, remove baroque regex - add OneOf for FQDN selector pattern vs. name - add pre-existing MaxItems for port & ICMP rules - add OneOf for L7 filter types None of these add any new restrictions; they were always in the policy engine. Now these validation errors will be caught by the apiserver. Signed-off-by: Casey Callendrello <cdc@isovalent.com>
7a350f3
to
d543969
Compare
/test |
Copying some logic from
Sanitize()
in to CRD validations:cidr
format directly, remove baroque regexNone of these add any new restrictions; they were always in the policy engine. Now these validation errors will be caught by the apiserver.