feat: added validation check for ensuring the existence of only 'any'/'all'

[yashvardhan-kukreja]

Related issue

closes #1765

What type of PR is this

/kind feature

Proposed changes

After this PR
If someone declares preconditions or validate.deny.conditions containing any/all, they won't be able to specify any other sub-field apart from any/all.
For example, the following policy:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: cluster-cm-array-example
spec:
  validationFailureAction: enforce 
  background: false 
  rules:
  - name: sample-rule
    context:
      - name: ops-cm
        configMap:
          name: ops-cm
          namespace: default
    match:
      resources:
        kinds:
        - Deployment
    validate:
      message: "The role {{ request.object.metadata.annotations.role }} is not in the allowed list of roles: {{ \"roles-dictionary\".data.\"allowed-roles\" }}."
      deny:
        conditions:
          any:
          - key: "{{ request.operation }}"
            operator: Equals
            value:  "{{ \"ops-cm\".data.\"deny-ops\"}}"
          foo:
          - key: "{{ request.operation }}"
            operator: Equals
            value:  "{{ \"ops-cm\".data.\"deny-ops\"}}"

When the above policy will be applied, the following error will be generated:

Error from server: error when creating "cpol.yaml": admission webhook "validate-policy.kyverno.svc" denied the request: path: spec.rules[0].validate.deny.conditions: error occurred while parsing preconditions/validate.deny.conditions: unknown field 'foo' found under preconditions/validate.deny.conditions

Before this PR
If someone specified an ambiguous sub-field like foo under preconditions or validate.deny.conditions, kyverno wouldn't raise an error like above.
For example, the following policy:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: cluster-cm-array-example
spec:
  validationFailureAction: enforce 
  background: false 
  rules:
  - name: sample-rule
    context:
      - name: ops-cm
        configMap:
          name: ops-cm
          namespace: default
    match:
      resources:
        kinds:
        - Deployment
    validate:
      message: "The role {{ request.object.metadata.annotations.role }} is not in the allowed list of roles: {{ \"roles-dictionary\".data.\"allowed-roles\" }}."
      deny:
        conditions:
          any:
          - key: "{{ request.operation }}"
            operator: Equals
            value:  "{{ \"ops-cm\".data.\"deny-ops\"}}"
          foo:
          - key: "{{ request.operation }}"
            operator: Equals
            value:  "{{ \"ops-cm\".data.\"deny-ops\"}}"

On applying the above policy, kyverno wouldn't raise any error. And behind the scenes, whenever the above policy's rule will evaluate an admission request, it would simplpy ignore the conditions specified under ambiguous sub-fields like foo but that's not ideal because user might be under the wrong assumption that that condition specified under foo would still be evaluating the incoming admission requests and working fine, (this might occur if the user, while writing a policy, unknowingly wrote a type like anyz or allz)

Checklist

• [] I have read the contributing guidelines.
• [] I have added tests that prove my fix is effective or that my feature works.
• [] I have added or changed the documentation.
  • If not, I have raised an issue in kyverno/website to track the doc update:

Further comments

[yashvardhan-kukreja]

@chipzoller hope this looks fine :)

[chipzoller]

Looks good. I'm not sure if we want to enforce there be a maximum of one all statement within those fields. Multiple any statements would be valid, but only a single all. Probably not a big deal either way, but it would seem to be a bit tidier.

[realshuting]

Thanks @yashvardhan-kukreja, look good!