Merge branch 'main' into main

.github/workflows/check-links.yaml

@@ -11,11 +11,11 @@ jobs:
   linkChecker:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
+      - uses: actions/checkout@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871 # v4.2.1
 
       - name: Check unrendered links
         id: lychee_unrendered
-        uses: lycheeverse/lychee-action@2b973e86fc7b1f6b36a93795fe2c9c6ae1118621 # v1.10.0
+        uses: lycheeverse/lychee-action@7da8ec1fc4e01b5a12062ac6c589c10a4ce70d67 # v2.0.0
         env:
           GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
         with:
@@ -48,7 +48,7 @@ jobs:
 
       # - name: Check rendered links
       #   id: lychee_rendered
-      #   uses: lycheeverse/lychee-action@2b973e86fc7b1f6b36a93795fe2c9c6ae1118621 # v1.10.0
+      #   uses: lycheeverse/lychee-action@7da8ec1fc4e01b5a12062ac6c589c10a4ce70d67 # v2.0.0
       #   env:
       #     GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
       #   with:

README.md

@@ -41,6 +41,15 @@ hugo server
 
 By default, Hugo runs the website at: http://localhost:1313 and will re-build the site on changes.
 
+**Note for Github Codespaces User:** You will be required to install the hugo extended version. To do so download the extended version from [hugo release](https://github.com/gohugoio/hugo/releases) based on your operation system (mostly it is Ubuntu for Codespaces). Use the below commands to install and then move the hugo directory to `usr/local/hugo/bin/hugo`
+```
+wget https://github.com/gohugoio/hugo/releases/download/v0.135.0/hugo_extended_0.135.0_linux-amd64.deb
+sudo dpkg -i hugo_extended_0.135.0_linux-amd64.deb
+rm hugo_extended_0.135.0_linux-amd64.deb
+sudo mv /usr/local/bin/hugo /usr/local/hugo/bin/hugo
+```
+Finally, Check the hugo version by running: `hugo version`
+
 ## Update Docsy theme
 
 The project uses [Hugo Modules](https://gohugo.io/hugo-modules/) to manage the theme:

content/en/_index.md

@@ -4,7 +4,7 @@ linkTitle = "Kyverno"
 +++
 
 {{< blocks/cover title="Kyverno" image_anchor="top" height="full" color="dark" >}}
-# Policy Management. Simplified. { class="text-center" }
+# Policy as Code, Simplified! { class="text-center" }
 
 <div class="mt-5 mx-auto">
 	<a class="btn btn-lg btn-primary mr-3 mb-4" href="#about-kyverno">
@@ -28,18 +28,19 @@ linkTitle = "Kyverno"
 <br/>
 
 <h2>
-Policy Management for Kubernetes and cloud native environments.
+The Kyverno project provides a comprehensive set of tools to manage the complete Policy-as-Code (PaC) lifecycle for Kubernetes and other cloud native environments
 </h2>
 <br/>
 
 <p style="line-height:1.5">
-Kyverno policies are declarative YAML resources and <b>no new language</b> is required to write policies. This allows using familiar tools such as <code style="font-size: 1.35rem">kubectl</code>, <code style="font-size: 1.35rem">git</code>, and <code style="font-size: 1.35rem">kustomize</code> to manage policies. For efficient handling of complex logic, Kyverno supports both JMESPath and the Common Expressions Language (CEL) languages. 
+
+Kyverno policies are declarative YAML resources and <b>no new language</b> is required. Kyverno enables use of familiar tools such as <code style="font-size: 1.35rem">kubectl</code>, <code style="font-size: 1.35rem">git</code>, and <code style="font-size: 1.35rem">kustomize</code> to manage policies. Kyverno supports JMESPath and the Common Expressions Language (CEL) for efficient handling of complex logic.
 
 In Kubernetes environments, Kyverno policies can <b>validate, mutate, generate, and cleanup</b> any Kubernetes resource, including custom resources. To help secure the software supply chain Kyverno policies can <b>verify OCI container image signatures and artifacts</b>. Kyverno policy reports and policy exceptions are also Kubernetes API resources.
 
-The **Kyverno CLI** can be used to apply and test policies off-cluster e.g., as part of a CI/CD pipeline. 
+The **Kyverno CLI** can be used to apply and test policies off-cluster e.g., as part of an IaC and CI/CD pipelines. 
 
-**Kyverno Policy Reporter**  provides in-cluster report management with a graphical web-based user interface. 
+**Kyverno Policy Reporter** provides report management with a graphical web-based user interface. 
 
 **Kyverno JSON** allows applying Kyverno policies in non-Kubernetes environments and on any JSON payload.
 

content/en/blog/general/why-chainsaw-is-unique/index.md

@@ -120,14 +120,14 @@ spec:
   template:
     spec:
       (containers[?securityContext == null]):
-        (len(@)): 0
+        (length(@)): 0
 ```
 
 In the assertion above, the first three fields `spec`, `template`, and `spec` are basic projections that simply take the content of their respective fields and pass that to descendants.
 
-`(containers[?securityContext == null])` is a JMESPath expression filtering the `containers` array, selecting only the element where `securityContext` is `null`. This projection results in a new array that is passed to the descendant (`(len(@))` in this case).
+`(containers[?securityContext == null])` is a JMESPath expression filtering the `containers` array, selecting only the element where `securityContext` is `null`. This projection results in a new array that is passed to the descendant (`(length(@))` in this case).
 
-`(len(@))` is another JMESPath expression that computes the length of the array. There's no more descendant at this point. We're at a leaf of the YAML tree and the array length we just computed is then compared against 0.
+`(length(@))` is another JMESPath expression that computes the length of the array. There's no more descendant at this point. We're at a leaf of the YAML tree and the array length we just computed is then compared against 0.
 
 If the comparison matches, the assertion will be considered valid; if not, it will be considered failed.
 

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

@@ -806,7 +806,7 @@ With the `apply` command, Kubernetes ValidatingAdmissionPolicies can be applied
 Policy manifest (check-deployment-replicas.yaml):
 
 ```yaml
-apiVersion: admissionregistration.k8s.io/v1beta1
+apiVersion: admissionregistration.k8s.io/v1
 kind: ValidatingAdmissionPolicy
 metadata:
   name: check-deployments-replicas
@@ -863,7 +863,7 @@ The below example applies a `ValidatingAdmissionPolicyBinding` along with the po
 
 Policy manifest (check-deployment-replicas.yaml):
 ```yaml
-apiVersion: admissionregistration.k8s.io/v1beta1
+apiVersion: admissionregistration.k8s.io/v1
 kind: ValidatingAdmissionPolicy
 metadata:
   name: "check-deployment-replicas"
@@ -882,7 +882,7 @@ spec:
   validations:
   - expression: object.spec.replicas <= 5
 ---
-apiVersion: admissionregistration.k8s.io/v1beta1
+apiVersion: admissionregistration.k8s.io/v1
 kind: ValidatingAdmissionPolicyBinding
 metadata:
   name: "check-deployment-replicas-binding"

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

@@ -49,7 +49,7 @@ results:
   resources: # optional, primarily for `validate` rules.
   - <namespace_1/name_1>
   - <namespace_2/name_2>
-  patchedResource: <file_name.yaml> # when testing a mutate rule this field is required.
+  patchedResources: <file_name.yaml> # when testing a mutate rule this field is required.
   generatedResource: <file_name.yaml> # when testing a generate rule this field is required.
   cloneSourceResource: <file_name.yaml> # when testing a generate rule that uses `clone` object this field is required.
   kind: <kind>
@@ -416,14 +416,14 @@ results:
     rule: add-default-requests
     resources:
     - nginx-demo1
-    patchedResource: patchedResource1.yaml
+    patchedResources: patchedResource1.yaml
     kind: Pod
     result: pass
   - policy: add-default-resources
     rule: add-default-requests
     resources:
     - nginx-demo2
-    patchedResource: patchedResource2.yaml
+    patchedResources: patchedResource2.yaml
     kind: Pod
     result: skip
 ```
@@ -701,7 +701,7 @@ Below is an example of testing a ValidatingAdmissionPolicy against two resources
 Policy manifest (disallow-host-path.yaml):
 
 ```yaml
-apiVersion: admissionregistration.k8s.io/v1beta1
+apiVersion: admissionregistration.k8s.io/v1
 kind: ValidatingAdmissionPolicy
 metadata:
   name: disallow-host-path
@@ -823,7 +823,7 @@ In the below example, a `ValidatingAdmissionPolicy` and its corresponding `Valid
 Policy manifest (`check-deployment-replicas.yaml`):
 
 ```yaml
-apiVersion: admissionregistration.k8s.io/v1beta1
+apiVersion: admissionregistration.k8s.io/v1
 kind: ValidatingAdmissionPolicy
 metadata:
   name: "check-deployment-replicas"
@@ -842,7 +842,7 @@ spec:
   validations:
   - expression: object.spec.replicas <= 2
 ---
-apiVersion: admissionregistration.k8s.io/v1beta1
+apiVersion: admissionregistration.k8s.io/v1
 kind: ValidatingAdmissionPolicyBinding
 metadata:
   name: "check-deployment-replicas-binding"

content/en/docs/monitoring/_index.md

@@ -138,11 +138,19 @@ metricsConfig:
 
   # Per Metric configuration, allows disabling metrics, dropping labels and change the bucket boundaries.
   metricsExposure:
+    # Counter disabled
+    kyverno_policy_rule_info_total:
+      enabled: false
+    # Histogram disabled
+    kyverno_admission_review_duration_seconds:
+      enabled: false
+    # Counter with customized dimensions
+    kyverno_admission_requests:
+      disabledLabelDimensions: ["resource_namespace", "resource_kind", "resource_request_operation"]
+    # Histogram with custom boundaries and dimensions
     kyverno_policy_execution_duration_seconds:
       disabledLabelDimensions: ["resource_kind", "resource_namespace", "resource_request_operation"]
       bucketBoundaries: [0.005, 0.01, 0.025]
-    kyverno_admission_review_duration_seconds:
-      enabled: false
 ...
 ```
 

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

@@ -14,7 +14,7 @@ To configure Kyverno to generate reports for ValidatingAdmissionPolicies, set th
 Create a ValidatingAdmissionPolicy that checks the Deployment replicas and a ValidatingAdmissionPolicyBinding that binds the policy to a namespace whose labels set to `environment: staging`.
 
 ```yaml
-apiVersion: admissionregistration.k8s.io/v1beta1
+apiVersion: admissionregistration.k8s.io/v1
 kind: ValidatingAdmissionPolicy
 metadata:
   name: "check-deployment-replicas"
@@ -33,7 +33,7 @@ spec:
   validations:
   - expression: object.spec.replicas <= 5
 ---
-apiVersion: admissionregistration.k8s.io/v1beta1
+apiVersion: admissionregistration.k8s.io/v1
 kind: ValidatingAdmissionPolicyBinding
 metadata:
   name: "check-deployment-replicas-binding"

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

@@ -5,10 +5,6 @@ description: >
 weight: 70
 ---
 
-{{% alert title="Warning" color="warning" %}}
-Cleanup policies are a **beta** feature.
-{{% /alert %}}
-
 Kyverno has the ability to cleanup (i.e., delete) existing resources in a cluster in two different ways. The first way is via a declarative policy definition in either a `CleanupPolicy` or `ClusterCleanupPolicy`. See the section on [cleanup policies](#cleanup-policy) below for more details. The second way is via a reserved time-to-live (TTL) label added to a resource. See the [cleanup label](#cleanup-label) section for further details.
 
 ## Cleanup Policy

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

@@ -5,10 +5,6 @@ description: >
 weight: 80
 ---
 
-{{% alert title="Warning" color="warning" %}}
-Policy exceptions are a **beta** feature. Normal semantic versioning and compatibility rules will not apply.
-{{% /alert %}}
-
 Although Kyverno policies contain multiple methods to provide fine-grained control as to which resources they act upon in the form of [`match`/`exclude` blocks](match-exclude.md#match-statements), [preconditions](preconditions.md) at multiple hierarchies, [anchors](validate.md#anchors), and more, all these mechanisms have in common that the resources which they are intended to exclude must occur in the same rule definition. This may be limiting in situations where policies may not be directly editable, or doing so imposes an operational burden.
 
 For example, in organizations where multiple teams must interact with the same cluster, a team responsible for policy authoring and administration may not be the same team responsible for submission of resources. In these cases, it can be advantageous to decouple the policy definition from certain exclusions. Additionally, there are often times where an organization or team must allow certain exceptions which would violate otherwise valid rules but on a one-time basis if the risks are known and acceptable.

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

@@ -714,6 +714,20 @@ The data returned by GlobalContextEntries may vary depending on whether it is a
 GlobalContextEntries must be in a healthy state (i.e., there is a response received from the remote endpoint) in order for the policies which reference them to be considered healthy. A GlobalContextEntry which is in a `not ready` state will cause any/all referenced policies to also be in a similar state and therefore will not be processed. Creation of a policy referencing a GlobalContextEntry which either does not exist or is not ready will print a warning notifying users.
 {{% /alert %}}
 
+#### Default values for API calls
+In the case where the api server returns an error, `default` can be used to provide a fallback value for the api call context entry. The following example shows how to add default value to context entries:
+
+```yaml
+...
+    context:
+    - name: currentnamespace
+      apiCall:
+        urlPath: "/api/v1/namespaces/{{ request.namespace }}"
+        jmesPath: metadata.name
+        default: default
+...
+```
+
 ## Variables from Image Registries
 
 A context can also be used to store metadata on an OCI image by using the `imageRegistry` context type. By using this external data source, a Kyverno policy can make decisions based on details of the container image that occurs as part of an incoming resource.
@@ -736,6 +750,7 @@ the output `imageData` variable will have a structure which looks like the follo
     "registry":      "ghcr.io",
     "repository":    "kyverno/kyverno",
     "identifier":    "latest",
+    "imageIndex":    imageIndex,
     "manifest":      manifest,
     "configData":    config,
 }
@@ -755,7 +770,7 @@ The `imageData` variable represents a "normalized" view of an image after any re
 ```
 {{% /alert %}}
 
-The `manifest` and `config` keys contain the output from `crane manifest <image>` and `crane config <image>` respectively.
+The `imageIndex`, `manifest` and `config` keys contain the output from `crane manifest <image>` and `crane config <image>` respectively.
 
 For example, one could inspect the labels, entrypoint, volumes, history, layers, etc of a given image. Using the [crane](https://github.com/google/go-containerregistry/tree/main/cmd/crane) tool, show the config of the `ghcr.io/kyverno/kyverno:latest` image: