-
Notifications
You must be signed in to change notification settings - Fork 850
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
[Feature] CLI test command should validate the policy under test #4365
Comments
If no one is working on this I would like to work on this issue. @zswanson |
Thanks for the interest @codeWithUtkarsh ! Kyverno policy does have the schema defined and can be used for policy validation. If you could share the investigated solutions, I'd gladly discuss them and help. |
Problem StatementThe cli
|
@codeWithUtkarsh - thanks for looking into the issue. It seems there's some misunderstanding of Kyverno validate policies and validate Kyverno policies. The former is used to validate resources via Kyverno policies while the latter is to perform validation checks for Kyverno policies. Take this policy as an example: apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: validate-gateway-port-protocol
spec:
validationFailureAction: enforce
background: false
rules:
- name: validate-gateway-port-protocol
match:
all:
- resources:
kinds:
- Gateway
namespaceSelector:
matchLabels:
istio/rev: "default" If you create that to the cluster, kubectl returns the below error saying that the policy is invalid due to the schema mismatch.
We want the same behavior with Kyverno CLI, possibly a new command |
I meant the same @realshuting Maybe the added source have created confusion. I understand that the intend of this issue is to do a grammatical/syntactical check using kyverno cli. I will look at OpenAPI schema validation implemented in kubectl. |
What we need to do here is embed the same validation checks that Kyverno does as part of its internal policy validation into the CLI. It should run these checks implicitly for every policy fed to either the |
cc @vyankyGH and @Prateeknandle |
@codeWithUtkarsh are you still working on this issue? If not, please unassign yourself so other contributors know it is available. |
Related: #2302 |
We simply need to use strict marshalling. |
Thanks for reporting, this will be fixed in 1.11. |
Problem Statement
It is currently possible to write a ClusterPolicy (or Policy) that is malformed such that the Kyverno controller would reject the ClusterPolicy if applied to a cluster. Depending on the the extent of the bugs in the policy, the
kyverno test
CLI command may continue to pass/fail tests appropriately.For example:
The rule above had incorrect indentation where the
namespaceSelector
is at the same level asresources
(it should be a child element ofresources
). The clikyverno test
command ran all tests without error; it was only on trying to apply the policy to a cluster that schema validation occurred and let us know that the policy wasn't constructed correctly.In other more subtle problems this may cause
kyverno test
score the tests as 'error' or 'notfound' with little or no explanation of the issue even at max log verbosity. ie, usingoperator: Equal
rather thanoperator: Equals
in a precondition. A dryrun apply against the server immediately gives good feedback from the controller however.Here is a second example of bad indentation that allowed tests to pass, but failed when trying to apply the policy. The
preconditions
stanza is incorrectly indented under thematch
.Solution Description
The kyverno CLI should either offer a separate
validate
command that can test a policy against the schema and report errors, and/or the kyverno CLI should incorporate that as part of the existingtest
command before the tests execute. If the policy violates the schema, the tests should not execute.Alternatives
To workaround this problem a policy author must (dryrun) apply a policy repeatedly to a cluster running the kyverno controller.
Additional Context
No response
Slack discussion
No response
Research
The text was updated successfully, but these errors were encountered: