docs: add warning for the validationFailureAction deprecated field

content/en/docs/applying-policies/_index.md

@@ -13,7 +13,7 @@ The [Kyverno Policies](/policies/) repository contains several policies you can
 
 On installation, Kyverno runs as a [dynamic admission controller](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) in a Kubernetes cluster. Kyverno receives validating and mutating admission webhook HTTP callbacks from the Kubernetes API server and applies matching policies to return results that enforce admission policies or reject requests.
 
-Policies with validation rules can be used to block insecure or non-compliant configurations by setting the [`validationFailureAction`](../writing-policies/validate.md#validation-failure-action) to `Enforce`. Or, validation rules can be applied using periodic scans with results available as [policy reports](../policy-reports/).
+Policies with validation rules can be used to block insecure or non-compliant configurations by setting the [`failureAction`](../writing-policies/validate.md#failure-action) to `Enforce`. Or, validation rules can be applied using periodic scans with results available as [policy reports](../policy-reports/).
 
 Rules in a policy are applied in the order of definition. During [admission control](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), mutation rules are applied before validation rules. This allows validation of changes made during mutation. Note that **all** mutation rules are applied first across all policies before any validation rules are applied.
 

content/en/docs/introduction/quick-start.md

@@ -22,7 +22,7 @@ Next, select the quick start guide in which you are interested. Alternatively, s
 
 In the validation guide, you will see how simple an example Kyverno policy can be which ensures a label called `team` is present on every Pod. Validation is the most common use case for policy and functions as a "yes" or "no" decision making process. Resources which are compliant with the policy are allowed to pass ("yes, this is allowed") and those which are not compliant may not be allowed to pass ("no, this is not allowed"). An additional effect of these validate policies is to produce Policy Reports. A [Policy Report](../policy-reports/_index.md) is a custom Kubernetes resource, produced and managed by Kyverno, which shows the results of policy decisions upon allowed resources in a user-friendly way.
 
-Add the policy below to your cluster. It contains a single validation rule that requires that all Pods have the `team` label. Kyverno supports different rule types to validate, mutate, generate, cleanup, and verify image configurations. The field `validationFailureAction` is set to `Enforce` to block Pods that are non-compliant. Using the default value `Audit` will report violations but not block requests.
+Add the policy below to your cluster. It contains a single validation rule that requires that all Pods have the `team` label. Kyverno supports different rule types to validate, mutate, generate, cleanup, and verify image configurations. The field `failureAction` is set to `Enforce` to block Pods that are non-compliant. Using the default value `Audit` will report violations but not block requests.
 
 ```yaml
 kubectl create -f- << EOF
@@ -31,7 +31,6 @@ kind: ClusterPolicy
 metadata:
   name: require-labels
 spec:
-  validationFailureAction: Enforce
   rules:
   - name: check-team
     match:
@@ -40,6 +39,7 @@ spec:
           kinds:
           - Pod
     validate:
+      failureAction: Enforce
       message: "label 'team' is required"
       pattern:
         metadata:

content/en/docs/kyverno-cli/usage/apply.md

@@ -264,7 +264,6 @@ kind: ClusterPolicy
 metadata:
   name: cm-globalval-example
 spec:
-  validationFailureAction: Enforce
   background: false
   rules:
     - name: validate-mode
@@ -274,6 +273,7 @@ spec:
             kinds:
               - Pod
       validate:
+        failureAction: Enforce
         message: "The value {{ request.mode }} for val1 is not equal to 'dev'."
         deny:
           conditions:
@@ -362,7 +362,6 @@ kind: ClusterPolicy
 metadata:
   name: enforce-pod-name
 spec:
-  validationFailureAction: Audit
   background: true
   rules:
     - name: validate-name
@@ -378,6 +377,7 @@ spec:
                 values:
                 - managed
       validate:
+        failureAction: Audit
         message: "The Pod must end with -nginx"
         pattern:
           metadata:
@@ -446,7 +446,6 @@ metadata:
   annotations:
     pod-policies.kyverno.io/autogen-controllers: DaemonSet,Deployment,StatefulSet
 spec:
-  validationFailureAction: Enforce
   background: false
   rules:
     - name: example-configmap-lookup
@@ -495,7 +494,7 @@ policies:
           dictionary.data.env: dev1
 ```
 
-Policies that have their validationFailureAction set to `Audit` can be set to produce a warning instead of a failure using the `--audit-warn` flag. This will also cause a non-zero exit code if no enforcing policies failed.
+Policies that have their failureAction set to `Audit` can be set to produce a warning instead of a failure using the `--audit-warn` flag. This will also cause a non-zero exit code if no enforcing policies failed.
 
 ```sh
 kyverno apply /path/to/policy.yaml --resource /path/to/resource.yaml --audit-warn
@@ -551,7 +550,6 @@ kind: ClusterPolicy
 metadata:
   name: require-pod-requests-limits
 spec:
-  validationFailureAction: Audit
   rules:
   - name: validate-resources
     match:
@@ -560,6 +558,7 @@ spec:
           kinds:
           - Pod
     validate:
+      failureAction: Audit
       message: "CPU and memory resource requests and limits are required"
       pattern:
         spec:
@@ -703,7 +702,6 @@ kind: ClusterPolicy
 metadata:
   name: max-containers
 spec:
-  validationFailureAction: Enforce
   background: false
   rules:
   - name: max-two-containers
@@ -713,6 +711,7 @@ spec:
           kinds:
           - Pod
     validate:
+      failureAction: Enforce
       message: "A maximum of 2 containers are allowed inside a Pod."
       deny:
         conditions:

content/en/docs/kyverno-cli/usage/test.md

@@ -228,7 +228,6 @@ kind: ClusterPolicy
 metadata:
   name: disallow-latest-tag
 spec:
-  validationFailureAction: Audit
   rules:
   - name: require-image-tag
     match:
@@ -237,6 +236,7 @@ spec:
           kinds:
           - Pod
     validate:
+      failureAction: Audit
       message: "An image tag is required."  
       pattern:
         spec:
@@ -249,6 +249,7 @@ spec:
           kinds:
           - Pod
     validate:
+      failureAction: Audit
       message: "Using a mutable image tag e.g. 'latest' is not allowed."
       pattern:
         spec:
@@ -544,7 +545,6 @@ kind: ClusterPolicy
 metadata:
   name: disallow-host-namespaces
 spec:
-  validationFailureAction: Enforce
   background: false
   rules:
     - name: host-namespaces
@@ -554,6 +554,7 @@ spec:
             kinds:
               - Pod
       validate:
+        failureAction: Enforce
         message: >-
           Sharing the host namespaces is disallowed. The fields spec.hostNetwork,
           spec.hostIPC, and spec.hostPID must be unset or set to `false`.          

content/en/docs/policy-reports/_index.md

@@ -7,7 +7,7 @@ weight: 60
 
 Policy reports are Kubernetes Custom Resources, generated and managed automatically by Kyverno, which contain the results of applying matching Kubernetes resources to Kyverno ClusterPolicy or Policy resources. They are created for `validate` and `verifyImages` rules when a resource is matched by one or more rules according to the policy definition. If resources violate multiple rules, there will be multiple entries. When resources are deleted, their entry will be removed from the report. Reports, therefore, always represent the current state of the cluster and do not record historical information.
 
-For example, if a validate policy in `Audit` mode exists containing a single rule which requires that all resources set the label `team` and a user creates a Pod which does not set the `team` label, Kyverno will allow the Pod's creation but record it as a `fail` result in a policy report due to the Pod being in violation of the policy and rule. Policies configured with `spec.validationFailureAction: Enforce` immediately block violating resources and results will only be reported for `pass` evaluations. Policy reports are an ideal way to observe the impact a Kyverno policy may have in a cluster without causing disruption. The insights gained from these policy reports may be used to provide valuable feedback to both users/developers so they may take appropriate action to bring offending resources into alignment, and to policy authors or cluster operators to help them refine policies prior to changing them to `Enforce` mode. Because reports are decoupled from policies, standard Kubernetes RBAC can then be applied to separate those who can see and manipulate policies from those who can view reports.
+For example, if a validate policy in `Audit` mode exists containing a single rule which requires that all resources set the label `team` and a user creates a Pod which does not set the `team` label, Kyverno will allow the Pod's creation but record it as a `fail` result in a policy report due to the Pod being in violation of the policy and rule. Policies configured with `spec.rules[*].validate[*].failureAction: Enforce` immediately block violating resources and results will only be reported for `pass` evaluations. Policy reports are an ideal way to observe the impact a Kyverno policy may have in a cluster without causing disruption. The insights gained from these policy reports may be used to provide valuable feedback to both users/developers so they may take appropriate action to bring offending resources into alignment, and to policy authors or cluster operators to help them refine policies prior to changing them to `Enforce` mode. Because reports are decoupled from policies, standard Kubernetes RBAC can then be applied to separate those who can see and manipulate policies from those who can view reports.
 
 Policy reports are created based on two different triggers: an admission event (a `CREATE`, `UPDATE`, or `DELETE` action performed against a resource) or the result of a background scan discovering existing resources. Policy reports, like Kyverno policies, have both Namespaced and cluster-scoped variants; a `PolicyReport` is a Namespaced resource while a `ClusterPolicyReport` is a cluster-scoped resource. Reports are stored in the cluster on a per resource basis. Every namespaced resource will (eventually) have an associated `PolicyReport` and every clustered resource will (eventually) have an associated `ClusterPolicyReport`.
 

content/en/docs/policy-reports/background.md

@@ -22,20 +22,20 @@ Background scanning, enabled by default in a `Policy` or `ClusterPolicy` object
 
 Background scanning occurs on a periodic basis (one hour by default) and offers some configuration options via [container flags](../installation/customization.md#container-flags).
 
-When background scanning is enabled, regardless of whether the policy's `validationFailureAction` is set to `Enforce` or `Audit`, the results will be recorded in a report. To see the specifics of how reporting works with background scans, refer to the tables below.
+When background scanning is enabled, regardless of whether the policy's `failureAction` is set to `Enforce` or `Audit`, the results will be recorded in a report. To see the specifics of how reporting works with background scans, refer to the tables below.
 
 **Reporting behavior when `background: true`**
 
 |                                  | New Resource | Existing Resource |
 |----------------------------------|--------------|-------------------|
-| `validationFailureAction: Enforce` | Pass only         | Report            |
-| `validationFailureAction: Audit`   | Report       | Report            |
+| `failureAction: Enforce` | Pass only         | Report            |
+| `failureAction: Audit`   | Report       | Report            |
 
 **Reporting behavior when `background: false`**
 
 |                                  | New Resource | Existing Resource |
 |----------------------------------|--------------|-------------------|
-| `validationFailureAction: Enforce` | Pass only         | None              |
-| `validationFailureAction: Audit`   | Report       | None              |
+| `failureAction: Enforce` | Pass only         | None              |
+| `failureAction: Audit`   | Report       | None              |
 
 Also, policy rules that are written using either certain variables from [AdmissionReview](../writing-policies/variables.md#variables-from-admission-review-requests) request information (e.g. `request.userInfo`), or fields like Roles, ClusterRoles, and Subjects in `match` and `exclude` statements, cannot be applied to existing resources in the background scanning mode since that information must come from an AdmissionReview request and is not available if the resource exists. Hence, these rules must set `background` to `false` to disable background scanning. The exceptions to this are `request.object` and `request.namespace` variables as these will be translated from the current state of the resource.

content/en/docs/policy-reports/examples.md

@@ -18,7 +18,6 @@ metadata:
   name: secrets-not-from-env-vars
 spec:
   background: true
-  validationFailureAction: Audit
   rules:
   - name: secrets-not-from-env-vars
     match:
@@ -27,6 +26,7 @@ spec:
           kinds:
           - Pod
     validate:
+      failureAction: Audit
       message: "Secrets must be mounted as volumes, not as environment variables."
       pattern:
         spec:
@@ -76,7 +76,7 @@ summary:
   warn: 0
 ```
 
-Create another Pod which violates the rule in the sample policy. Because the rule is written with `validationFailureAction: Audit`, resources are allowed to be created which violate the rule. If this occurs, another entry will be created in the PolicyReport which denotes this condition as a FAIL. By contrast, if `validationFailureAction: Enforce` and an offending resource was attempted creation, it would be immediately blocked and therefore would not generate another entry in the report. However, if the resource passed then a PASS result would be created in the report.
+Create another Pod which violates the rule in the sample policy. Because the rule is written with `failureAction: Audit`, resources are allowed to be created which violate the rule. If this occurs, another entry will be created in the PolicyReport which denotes this condition as a FAIL. By contrast, if `failureAction: Enforce` and an offending resource was attempted creation, it would be immediately blocked and therefore would not generate another entry in the report. However, if the resource passed then a PASS result would be created in the report.
 
 ```yaml
 apiVersion: v1

content/en/docs/troubleshooting/_index.md

@@ -82,7 +82,7 @@ Use [Namespace selectors](../installation/customization.md#namespace-selectors)
     pod "busybox" deleted
     ```
 
-5. For `validate` policies, ensure that `validationFailureAction` is set to `Enforce` if your expectation is that applicable resources should be blocked. Most policies in the samples library are purposefully set to `Audit` mode so they don't have any unintended consequences for new users. It could be that, if the prior steps check out, Kyverno is working fine only that your policy is configured to not immediately block resources.
+5. For `validate` policies, ensure that `failureAction` is set to `Enforce` if your expectation is that applicable resources should be blocked. Most policies in the samples library are purposefully set to `Audit` mode so they don't have any unintended consequences for new users. It could be that, if the prior steps check out, Kyverno is working fine only that your policy is configured to not immediately block resources.
 
 6. Check and ensure you aren't creating a resource that is either excluded from Kyverno's processing by default, or that it hasn't been created in an excluded Namespace. Kyverno uses a ConfigMap by default called `kyverno` in the Kyverno Namespace to filter out some of these things. The key name is `resourceFilters` and more details can be found [here](../installation/customization.md#resource-filters).
 

content/en/docs/writing-policies/autogen.md

@@ -15,7 +15,6 @@ kind: ClusterPolicy
 metadata:
   name: restrict-image-registries
 spec:
-  validationFailureAction: Enforce
   rules:
   - name: validate-registries
     match:
@@ -24,6 +23,7 @@ spec:
           kinds:
           - Pod
     validate:
+      failureAction: Enforce
       message: "Images may only come from our internal enterprise registry."
       pattern:
         spec:
@@ -56,6 +56,7 @@ status:
       mutate: {}
       name: autogen-validate-registries
       validate:
+        failureAction: Enforce
         message: Images may only come from our internal enterprise registry.
         pattern:
           spec:
@@ -77,6 +78,7 @@ status:
       mutate: {}
       name: autogen-cronjob-validate-registries
       validate:
+        failureAction: Enforce
         message: Images may only come from our internal enterprise registry.
         pattern:
           spec:
@@ -139,7 +141,6 @@ kind: ClusterPolicy
 metadata:
   name: require-requests-limits
 spec:
-  validationFailureAction: Enforce
   background: true
   rules:
     - name: validate-resources
@@ -154,6 +155,7 @@ spec:
           operator: NotEquals
           value: skip
       validate:
+        failureAction: Enforce
         message: "CPU and memory resource requests and limits are required."
         pattern:
           spec:

content/en/docs/writing-policies/exceptions.md

@@ -36,7 +36,6 @@ kind: ClusterPolicy
 metadata:
   name: disallow-host-namespaces
 spec:
-  validationFailureAction: Enforce
   background: false
   rules:
     - name: host-namespaces
@@ -46,6 +45,7 @@ spec:
             kinds:
               - Pod
       validate:
+        failureAction: Enforce
         message: >-
           Sharing the host namespaces is disallowed. The fields spec.hostNetwork,
           spec.hostIPC, and spec.hostPID must be unset or set to `false`.
@@ -149,7 +149,6 @@ kind: ClusterPolicy
 metadata:
   name: policy-for-exceptions
 spec:
-  validationFailureAction: Enforce
   background: false
   rules:
   - name: require-match-name
@@ -159,6 +158,7 @@ spec:
           kinds:
           - PolicyException
     validate:
+      failureAction: Enforce
       message: >-
         An exception must explicitly specify a name for a resource match.
       pattern:
@@ -185,7 +185,6 @@ metadata:
   name: psa
 spec:
   background: true
-  validationFailureAction: Enforce
   rules:
   - name: restricted
     match:
@@ -194,6 +193,7 @@ spec:
           kinds:
           - Pod
     validate:
+      failureAction: Enforce
       podSecurity:
         level: restricted
         version: latest

content/en/docs/writing-policies/external-data-sources.md

@@ -120,7 +120,6 @@ kind: ClusterPolicy
 metadata:
   name: cm-array-example
 spec:
-  validationFailureAction: Enforce
   background: false
   rules:
   - name: validate-role-annotation
@@ -135,6 +134,7 @@ spec:
           kinds:
           - Deployment
     validate:
+      failureAction: Enforce
       message: "The role {{ request.object.metadata.annotations.role }} is not in the allowed list of roles: {{ \"roles-dictionary\".data.\"allowed-roles\" }}."
       deny:
         conditions:
@@ -517,7 +517,6 @@ kind: ClusterPolicy
 metadata:
   name: limits
 spec:
-  validationFailureAction: Enforce
   rules:
   - name: limit-lb-svc
     match:
@@ -533,6 +532,7 @@ spec:
         urlPath: "/api/v1/namespaces/{{ request.namespace }}/services"
         jmesPath: "items[?spec.type == 'LoadBalancer'] | length(@)"    
     validate:
+      failureAction: Enforce
       message: "Only one LoadBalancer service is allowed per namespace"
       deny:
         conditions:
@@ -558,7 +558,6 @@ kind: ClusterPolicy
 metadata:
   name: check-namespaces      
 spec:
-  validationFailureAction: Enforce
   rules:
   - name: call-extension
     match:
@@ -580,6 +579,7 @@ spec:
             <snip>
             -----END CERTIFICATE-----
     validate:
+      failureAction: Enforce
       message: "namespace {{request.namespace}} is not allowed"
       deny:
         conditions:
@@ -816,7 +816,6 @@ kind: ClusterPolicy
 metadata:
   name: imageref-demo
 spec:
-  validationFailureAction: Enforce
   rules:
   - name: no-root-images
     match:
@@ -828,6 +827,7 @@ spec:
           - CREATE
           - UPDATE
     validate:
+      failureAction: Enforce
       message: "Images run as root are not allowed."  
       foreach:
       - list: "request.object.spec.containers"