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:
rules:
- name: validate-gateway-port-protocol
match:
all:
- resources:
kinds:
- Gateway
namespaceSelector:
matchLabels:
istio/rev: "default"
The rule above had incorrect indentation where the namespaceSelector is at the same level as resources (it should be a child element of resources). The cli kyverno 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, using operator: Equal rather than operator: 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 the match.
rules:
- name: require-image-tag
match:
resources:
kinds:
- Pod
preconditions:
all:
- key: "{{ request.operation }}"
operator: AnyIn
value:
- CREATE
- UPDATE
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 existing test 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
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 testCLI command may continue to pass/fail tests appropriately.For example:
The rule above had incorrect indentation where the
namespaceSelectoris at the same level asresources(it should be a child element ofresources). The clikyverno testcommand 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 testscore the tests as 'error' or 'notfound' with little or no explanation of the issue even at max log verbosity. ie, usingoperator: Equalrather thanoperator: Equalsin 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
preconditionsstanza is incorrectly indented under thematch.Solution Description
The kyverno CLI should either offer a separate
validatecommand that can test a policy against the schema and report errors, and/or the kyverno CLI should incorporate that as part of the existingtestcommand 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