diff --git a/.github/dependabot.yml b/.github/dependabot.yml new file mode 100644 index 000000000..1b322341d --- /dev/null +++ b/.github/dependabot.yml @@ -0,0 +1,7 @@ +version: 2 +updates: + - package-ecosystem: github-actions + directory: / + schedule: + interval: daily + rebase-strategy: disabled \ No newline at end of file diff --git a/.github/workflows/check-links.yaml b/.github/workflows/check-links.yaml index 78ae796fb..09e636376 100644 --- a/.github/workflows/check-links.yaml +++ b/.github/workflows/check-links.yaml @@ -3,6 +3,9 @@ name: Check Links on: repository_dispatch: workflow_dispatch: + pull_request: + branches: + - main schedule: - cron: "0 0 * * *" @@ -10,13 +13,36 @@ jobs: linkChecker: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v3 + - name: Waiting for Netlify Preview + uses: jakepartusch/wait-for-netlify-action@f1e137043864b9ab9034ae3a5adc1c108e3f1a48 # v1.4 + id: wait-for-netflify-preview + with: + site_name: kyverno + max_timeout: 60 + + - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1 + + - name: Setup Hugo + uses: peaceiris/actions-hugo@16361eb4acea8698b220b76c0d4e84e1fd22c61d # v2.6.0 + with: + hugo-version: latest + extended: true + + - name: Install site dependencies + run: npm install --save-dev autoprefixer && npm install --save-dev postcss-cli && npm install -D postcss + + - name: Build site with Hugo + run: hugo --minify -b ${{ steps.wait-for-netflify-preview.outputs.url }} - name: Link Checker id: lychee - uses: lycheeverse/lychee-action@v1.5.0 + uses: lycheeverse/lychee-action@c053181aa0c3d17606addfe97a9075a32723548a # v1.9.3 env: GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}} + with: + fail: true + debug: false + args: --no-progress --github-token ${{secrets.GITHUB_TOKEN}} -c lychee.toml -E public # - name: Create Issue From File # if: steps.lychee.outputs.exit_code != 0 diff --git a/.lycheeignore b/.lycheeignore new file mode 100644 index 000000000..54efb75cf --- /dev/null +++ b/.lycheeignore @@ -0,0 +1,5 @@ +https://github.com/kyverno/website/issues/* +http://sodipodi.sourceforge.net* +http://purl.org* +https://github.com/kyverno/policies/openshift/ +gcpkms://* \ No newline at end of file diff --git a/content/en/blog/general/aws-irsa/index.md b/content/en/blog/general/aws-irsa/index.md index 71853b359..c17d82c9d 100644 --- a/content/en/blog/general/aws-irsa/index.md +++ b/content/en/blog/general/aws-irsa/index.md @@ -6,7 +6,7 @@ author: Shuting Zhao description: "Using Kyverno to verify images with IRSA" --- -When running workloads in Amazon Elastic Kubernetes Service (EKS), it is essential to ensure supply chain security by verifying container image signatures and other metadata. To achieve this, you can configure Kyverno, a CNCF policy engine designed for Kubernetes, to pull from ECR private registries for image verification. It's possible to [pass in the credentials via secrets](https://kyverno.io/docs/writing-policies/verify-images/sigstore/#using-private-registries), but that can get difficult to manage and automate across multiple clusters. In this blog post, we will explore an alternative method that simplifies the authentication process by leveraging Kyverno and IRSA (IAM Roles for Service Accounts) in EKS for image verification. +When running workloads in Amazon Elastic Kubernetes Service (EKS), it is essential to ensure supply chain security by verifying container image signatures and other metadata. To achieve this, you can configure Kyverno, a CNCF policy engine designed for Kubernetes, to pull from ECR private registries for image verification. It's possible to [pass in the credentials via secrets](/docs/writing-policies/verify-images/sigstore/#using-private-registries), but that can get difficult to manage and automate across multiple clusters. In this blog post, we will explore an alternative method that simplifies the authentication process by leveraging Kyverno and IRSA (IAM Roles for Service Accounts) in EKS for image verification. Applications, such as Kyverno, running within a Pod's containers can utilize the AWS SDK to make API requests to AWS services by leveraging AWS Identity and Access Management (IAM) permissions. IAM roles for service accounts enable the management of credentials for these applications. Instead of manually creating and distributing AWS credentials to the containers, you can associate an IAM role with a Kubernetes service account and configure your Pods to utilize this service account. The detailed steps for this process can be found in the [documentation](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html). In this blog, we will guide you through the complete process of enabling IAM roles for the Kyverno service account and demonstrate how to verify this using the Kyverno `verifyImages` rule. @@ -37,7 +37,7 @@ aws ec2 modify-instance-metadata-options --instance-id --http-toke ## Installing Kyverno -Once you have the cluster set up, you can use Helm to [install Kyverno into the cluster](https://kyverno.io/docs/installation/methods/): +Once you have the cluster set up, you can use Helm to [install Kyverno into the cluster](/docs/installation/methods/): ```sh helm upgrade --install kyverno kyverno/kyverno --namespace kyverno --create-namespace diff --git a/content/en/blog/general/jmespath/index.md b/content/en/blog/general/jmespath/index.md index e7b86de4e..289fb2389 100644 --- a/content/en/blog/general/jmespath/index.md +++ b/content/en/blog/general/jmespath/index.md @@ -10,20 +10,22 @@ The v1.9 release of Kyverno added several time related JMESPath filters. With th ## What is "JMESPath"? -[JMESPath](https://jmespath.org/) (pronounced "James path") is a JSON query language that allows you to declaratively specify how to extract elements from a JSON document. It is similar to JSONPath in Kubernetes. It can be used almost anywhere in Kyverno. +[JMESPath](https://jmespath.org/) (pronounced "James path") is a JSON query language that allows you to declaratively specify how to extract elements from a JSON document. It is similar to JSONPath in Kubernetes. It can be used almost anywhere in Kyverno. -Users may note that, many policies can be written with simple overlay patterns, others require more detailed selection and transformation. The latter is where JMESPath is useful. +Users may note that, many policies can be written with simple overlay patterns, others require more detailed selection and transformation. The latter is where JMESPath is useful. -Kyverno supports all the JMESPath filters in the [JMESPath specifications page](https://jmespath.org/specification.html) and also adds several custom filters. Refer to [Kyverno's JMESPath docs](https://main.kyverno.io/docs/writing-policies/jmespath/) for a comprehensive deep dive. +Kyverno supports all the JMESPath filters in the [JMESPath specifications page](https://jmespath.org/specification.html) and also adds several custom filters. Refer to [Kyverno's JMESPath docs](/docs/writing-policies/jmespath/) for a comprehensive deep dive. ## Why did we need these new filters? -Kyverno already supports all the availible filters in the upstream JMESpath library and some custom filters as well. But there was a lack of time related filters that come in useful at several places in Kyverno, such as + +Kyverno already supports all the available filters in the upstream JMESPath library and some custom filters as well. But there was a lack of time related filters that come in useful at several places in Kyverno, such as 1. When we want to add custom labels like last sync time. 2. Enforce a policy that checks whether the current time is after or before a specified time. 3. Perform job scheduling using cron expressions. ## What has been added? + In v1.9 release, Kyverno added 11 new time related filters to fulfill the above requirements and many more as well. 1. **Time_add:** We have added a filter to do arithmetic addition of a duration to a given time. The `time_add()` filter takes a time and a duration and returns a time. `time_add('2023-01-12T12:37:56-05:00','6h')` results in the value `"2023-01-12T18:37:56-05:00"`. It can come in useful purposes like adding some time to the current time and passing it as an argument for other time related filters. @@ -39,7 +41,9 @@ In v1.9 release, Kyverno added 11 new time related filters to fulfill the above 11. **Time_utc:** The `time_utc()` filter takes in a time in RFC 3339 format with a time offset and presents the same time in UTC/Zulu. It can be used in pair with `time_parse()` to convert it to UTC. ## How to use it? -An in-depth guide on how to use JMESPath filters in kyverno is present in the [Kyverno's JMESPath docs](https://main.kyverno.io/docs/writing-policies/jmespath/). + +An in-depth guide on how to use JMESPath filters in kyverno is present in the [Kyverno's JMESPath docs](/docs/writing-policies/jmespath/). + ## Summary -JMESPath is a powerful and robust tool for selecting, extracting and manipulating time in JSON. With the addition of the new time based filters, we have extended the capabilitites of JMES filters in kyverno and have opened new usecases. \ No newline at end of file +JMESPath is a powerful and robust tool for selecting, extracting and manipulating time in JSON. With the addition of the new time based filters, we have extended the capabilities of JMES filters in kyverno and have opened new usecases. diff --git a/content/en/blog/general/slsa-3/index.md b/content/en/blog/general/slsa-3/index.md index eb03e3a9e..0b5da43a1 100644 --- a/content/en/blog/general/slsa-3/index.md +++ b/content/en/blog/general/slsa-3/index.md @@ -154,7 +154,7 @@ The GitHub Action reusable workflow hosted by the SLSA GitHub Generator project The build service's users can not falsify the provenance. **Kyverno Processes:** -GitHub takes care of avoiding interference with the build system. GitHub uses ephemeral and isolated virtual machines, no one can persistently compromise this environment. GitHub automatically provisions a new VM for that job. When the job execution is finished, the VM is automatically decommissioned. Use of the [SLSA GitHub generator](https://github.com/slsa-framework/slsa-github-generator) separates the signing from building so the Kyverno build itself never has access to the signing secrets. Use of OIDC-based secrets through Sigstore's [keyless signing](https://github.com/sigstore/cosign/blob/main/KEYLESS.md) means the ephemeral signing secret is associated only with one specific build making it easy to detect secret theft and an attempt at signing something else. +GitHub takes care of avoiding interference with the build system. GitHub uses ephemeral and isolated virtual machines, no one can persistently compromise this environment. GitHub automatically provisions a new VM for that job. When the job execution is finished, the VM is automatically decommissioned. Use of the [SLSA GitHub generator](https://github.com/slsa-framework/slsa-github-generator) separates the signing from building so the Kyverno build itself never has access to the signing secrets. Use of OIDC-based secrets through Sigstore's [keyless signing](https://docs.sigstore.dev/signing/overview/) means the ephemeral signing secret is associated only with one specific build making it easy to detect secret theft and an attempt at signing something else. ### Provenance Content Requirements diff --git a/content/en/blog/general/using-cel-expressions-in-kyverno-policies/index.md b/content/en/blog/general/using-cel-expressions-in-kyverno-policies/index.md index c694a8eb0..1b9fa70b3 100644 --- a/content/en/blog/general/using-cel-expressions-in-kyverno-policies/index.md +++ b/content/en/blog/general/using-cel-expressions-in-kyverno-policies/index.md @@ -20,7 +20,7 @@ A policy consists of different clauses, such as: - Generate: It creates additional resources. - Verify Images: It verifies container image signatures using Cosign and Notary. -Refer to [Selecting Resources](https://kyverno.io/docs/writing-policies/match-exclude/) for more information. +Refer to [Selecting Resources](/docs/writing-policies/match-exclude/) for more information. > Each rule can contain only a single validate, mutate, generate, or verifyImages child declaration. @@ -550,7 +550,7 @@ deployment.apps/deployment-pass created Since Kubernetes has many higher-level controllers that directly or indirectly manage Pods: Deployment, DaemonSet, StatefulSet, Job, and CronJob resources, it’d be inefficient to write a policy that targets Pods and every higher-level controller. Kyverno solves this issue by supporting the automatic generation of policy rules for higher-level controllers from a rule written exclusively for a Pod. -Check the [autogen rules](https://kyverno.io/docs/writing-policies/autogen/) for more information. +Check the [autogen rules](/docs/writing-policies/autogen/) for more information. For example, when creating a validation policy like below, which disallows latest image tags, the policy applies to all resources capable of generating Pods. diff --git a/content/en/blog/general/why-chainsaw-is-unique/index.md b/content/en/blog/general/why-chainsaw-is-unique/index.md index d26872bf3..272c7075a 100644 --- a/content/en/blog/general/why-chainsaw-is-unique/index.md +++ b/content/en/blog/general/why-chainsaw-is-unique/index.md @@ -189,7 +189,7 @@ Now we can use the binding to write an assertion check taking the pod-level secu We covered all major features of assertion trees in this blog post. -Chainsaw doesn't directly implement assertion trees but relies on the [kyverno-json package](https://github.com/kyverno/kyverno-json). You can browse [the documentation](https://kyverno.github.io/kyverno-json/policies/asserts/#assertion-trees) to learn more about assertion trees, this documentation also applies to Chainsaw. The [kyverno-json playground](https://kyverno.github.io/kyverno-json/_playground/) is also a good resource to familiarise with assertion trees. +Chainsaw doesn't directly implement assertion trees but relies on the [kyverno-json package](https://github.com/kyverno/kyverno-json). You can browse [the documentation](https://kyverno.github.io/kyverno-json/latest/policies/asserts/#assertion-trees) to learn more about assertion trees, this documentation also applies to Chainsaw. The [kyverno-json playground](https://kyverno.github.io/kyverno-json/latest/_playground/) is also a good resource to familiarise with assertion trees. Note that JMESPath supports functions and also allows custom functions to be registered in the JMESPath interpreter. The supported list of functions is available [here](https://kyverno.github.io/chainsaw/latest/jp/functions/). diff --git a/content/en/docs/Applying Policies/_index.md b/content/en/docs/Applying Policies/_index.md index a452b8619..7888863be 100644 --- a/content/en/docs/Applying Policies/_index.md +++ b/content/en/docs/Applying Policies/_index.md @@ -25,6 +25,6 @@ Exceptions to policies may be defined in the rules themselves or with a separate ## In Pipelines -You can use the [Kyverno CLI](/docs/kyverno-cli/#apply) to apply policies to YAML resource manifest files as part of a software delivery pipeline. This command line tool allows integrating Kyverno into GitOps style workflows and checks for policy compliance of resource manifests before they are committed to version control and applied to clusters. +You can use the [Kyverno CLI](/docs/kyverno-cli/usage/apply/) to apply policies to YAML resource manifest files as part of a software delivery pipeline. This command line tool allows integrating Kyverno into GitOps style workflows and checks for policy compliance of resource manifests before they are committed to version control and applied to clusters. -Refer to the [Kyverno apply command section](/docs/kyverno-cli/#apply) for details on the CLI. And refer to the [Continuous Integration section](/docs/testing-policies/#continuous-integration) for an example of how to incorporate the CLI to apply and test policies in your pipeline. +Refer to the [Kyverno apply command section](/docs/kyverno-cli/usage/apply/) for details on the CLI. And refer to the [Continuous Integration section](/docs/testing-policies/#continuous-integration) for an example of how to incorporate the CLI to apply and test policies in your pipeline. diff --git a/content/en/docs/Installation/_index.md b/content/en/docs/Installation/_index.md index 9d9a887d6..b155712ee 100644 --- a/content/en/docs/Installation/_index.md +++ b/content/en/docs/Installation/_index.md @@ -53,7 +53,7 @@ Kyverno follows the same support policy as the Kubernetes project which is an N- \* Due to a known issue with Kubernetes 1.23.0-1.23.2, support for 1.23 begins at 1.23.3. -**NOTE:** The [Enterprise Kyverno](https://nirmata.com/kyverno-enterprise/) by Nirmata supports a wide range of Kubernetes versions for any Kyverno version. Refer to the Release Compatibility Matrix for the Enterprise Kyverno [here](https://docs.nirmata.io/n4k/release-compatibility-matrix/) or contact [Nirmata support](mailto:support@nirmata.com) for assistance. +**NOTE:** The [Enterprise Kyverno](https://nirmata.com/kyverno-enterprise/) by Nirmata supports a wide range of Kubernetes versions for any Kyverno version. Refer to the Release Compatibility Matrix for the Enterprise Kyverno [here](https://docs.nirmata.io/docs/n4k/release-compatibility-matrix/) or contact [Nirmata support](mailto:support@nirmata.com) for assistance. ## Security vs Operability diff --git a/content/en/docs/Kyverno CLI/reference/kyverno.md b/content/en/docs/Kyverno CLI/reference/kyverno.md index 32a50d095..65cc470d3 100644 --- a/content/en/docs/Kyverno CLI/reference/kyverno.md +++ b/content/en/docs/Kyverno CLI/reference/kyverno.md @@ -18,7 +18,7 @@ Kubernetes Native Policy Management. NOTE: To enable experimental commands, environment variable "KYVERNO_EXPERIMENTAL" should be set true or 1. - For more information visit https://kyverno.io/docs/kyverno-cli + For more information visit [here](/docs/kyverno-cli) ``` kyverno [flags] diff --git a/content/en/docs/Kyverno CLI/reference/kyverno_apply.md b/content/en/docs/Kyverno CLI/reference/kyverno_apply.md index 506bc50d8..d9bd064ff 100644 --- a/content/en/docs/Kyverno CLI/reference/kyverno_apply.md +++ b/content/en/docs/Kyverno CLI/reference/kyverno_apply.md @@ -11,7 +11,7 @@ Applies policies on resources. Applies policies on resources. - For more information visit https://kyverno.io/docs/kyverno-cli/#apply + For more information visit [here](/docs/kyverno-cli/usage/apply/) ``` kyverno apply [flags] diff --git a/content/en/docs/Kyverno CLI/reference/kyverno_jp.md b/content/en/docs/Kyverno CLI/reference/kyverno_jp.md index 12212a4c8..757229605 100644 --- a/content/en/docs/Kyverno CLI/reference/kyverno_jp.md +++ b/content/en/docs/Kyverno CLI/reference/kyverno_jp.md @@ -11,7 +11,7 @@ Provides a command-line interface to JMESPath, enhanced with Kyverno specific cu Provides a command-line interface to JMESPath, enhanced with Kyverno specific custom functions. - For more information visit https://kyverno.io/docs/kyverno-cli/#jp + For more information visit [here](/docs/kyverno-cli/usage/jp/) ``` kyverno jp [flags] diff --git a/content/en/docs/Kyverno CLI/reference/kyverno_jp_function.md b/content/en/docs/Kyverno CLI/reference/kyverno_jp_function.md index 166f00461..a2d701b48 100644 --- a/content/en/docs/Kyverno CLI/reference/kyverno_jp_function.md +++ b/content/en/docs/Kyverno CLI/reference/kyverno_jp_function.md @@ -11,7 +11,7 @@ Provides function informations. Provides function informations. - For more information visit https://kyverno.io/docs/kyverno-cli/#jp + For more information visit [here](/docs/kyverno-cli/usage/jp/) ``` kyverno jp function [function_name]... [flags] diff --git a/content/en/docs/Kyverno CLI/reference/kyverno_jp_parse.md b/content/en/docs/Kyverno CLI/reference/kyverno_jp_parse.md index a163a1cf0..cbaf08ce8 100644 --- a/content/en/docs/Kyverno CLI/reference/kyverno_jp_parse.md +++ b/content/en/docs/Kyverno CLI/reference/kyverno_jp_parse.md @@ -11,7 +11,7 @@ Parses jmespath expression and shows corresponding AST. Parses jmespath expression and shows corresponding AST. - For more information visit https://kyverno.io/docs/kyverno-cli/#jp + For more information visit [here](/docs/kyverno-cli/usage/jp/) ``` kyverno jp parse [-f file|expression]... [flags] diff --git a/content/en/docs/Kyverno CLI/reference/kyverno_jp_query.md b/content/en/docs/Kyverno CLI/reference/kyverno_jp_query.md index d50e5484b..27f10f0fe 100644 --- a/content/en/docs/Kyverno CLI/reference/kyverno_jp_query.md +++ b/content/en/docs/Kyverno CLI/reference/kyverno_jp_query.md @@ -11,7 +11,7 @@ Provides a command-line interface to JMESPath, enhanced with Kyverno specific cu Provides a command-line interface to JMESPath, enhanced with Kyverno specific custom functions. - For more information visit https://kyverno.io/docs/kyverno-cli/#jp + For more information visit [here](/docs/kyverno-cli/usage/jp/) ``` kyverno jp query [-i input] [-q query|query]... [flags] diff --git a/content/en/docs/Kyverno CLI/reference/kyverno_test.md b/content/en/docs/Kyverno CLI/reference/kyverno_test.md index f4cb284ac..aaac3c80d 100644 --- a/content/en/docs/Kyverno CLI/reference/kyverno_test.md +++ b/content/en/docs/Kyverno CLI/reference/kyverno_test.md @@ -17,7 +17,7 @@ Run tests from a local filesystem or a remote git repository. Users provide the path to the folder containing a kyverno-test.yaml file where the location could be on a local filesystem or a remote git repository. - For more information visit https://kyverno.io/docs/kyverno-cli/#test + For more information visit [here](/docs/kyverno-cli/usage/test/) ``` kyverno test [local folder or git repository]... [flags] diff --git a/content/en/docs/Kyverno CLI/reference/kyverno_version.md b/content/en/docs/Kyverno CLI/reference/kyverno_version.md index 8d8c5147a..2eceedaaa 100644 --- a/content/en/docs/Kyverno CLI/reference/kyverno_version.md +++ b/content/en/docs/Kyverno CLI/reference/kyverno_version.md @@ -11,7 +11,7 @@ Prints the version of Kyverno CLI. Prints the version of Kyverno CLI. - For more information visit https://kyverno.io/docs/kyverno-cli/#version + For more information visit [here](/docs/kyverno-cli/usage/) ``` kyverno version [flags] diff --git a/content/en/docs/Kyverno CLI/usage/test.md b/content/en/docs/Kyverno CLI/usage/test.md index fc00e2370..900a8cad0 100644 --- a/content/en/docs/Kyverno CLI/usage/test.md +++ b/content/en/docs/Kyverno CLI/usage/test.md @@ -65,7 +65,7 @@ The test declaration consists of the following parts: 5. The `userinfo` element which declares admission request data for subjects and roles. Optional depending on policy content. 6. The `results` element which declares the expected results. Depending on the type of rule being tested, this section may vary. -If needing to pass variables, such as those from [external data sources](/docs/writing-policies/external-data-sources/) like context variables built from [API calls](https://kyverno.io/docs/writing-policies/external-data-sources/#variables-from-kubernetes-api-server-calls) or others, a `variables.yaml` file can be defined with the same format as accepted with the `apply` command. If a variable needs to contain an array of strings, it must be formatted as JSON encoded. Like with the `apply` command, variables that begin with `request.object` normally do not need to be specified in the variables file as these will be sourced from the resource. Policies which trigger based upon `request.operation` equaling `CREATE` do not need a variables file. The CLI will assume a value of `CREATE` if no variable for `request.operation` is defined. +If needing to pass variables, such as those from [external data sources](/docs/writing-policies/external-data-sources/) like context variables built from [API calls](/docs/writing-policies/external-data-sources/#variables-from-kubernetes-api-server-calls) or others, a `variables.yaml` file can be defined with the same format as accepted with the `apply` command. If a variable needs to contain an array of strings, it must be formatted as JSON encoded. Like with the `apply` command, variables that begin with `request.object` normally do not need to be specified in the variables file as these will be sourced from the resource. Policies which trigger based upon `request.operation` equaling `CREATE` do not need a variables file. The CLI will assume a value of `CREATE` if no variable for `request.operation` is defined. ```yaml apiVersion: cli.kyverno.io/v1alpha1 diff --git a/content/en/docs/Testing Policies/_index.md b/content/en/docs/Testing Policies/_index.md index bf23688ff..884f46681 100644 --- a/content/en/docs/Testing Policies/_index.md +++ b/content/en/docs/Testing Policies/_index.md @@ -6,9 +6,9 @@ description: > Test Kyverno policies for effectiveness. --- -The [Kyverno CLI `test` command](/docs/kyverno-cli/#test) can be used to test if a policy is behaving as expected. +The [Kyverno CLI `test` command](/docs/kyverno-cli/usage/test/) can be used to test if a policy is behaving as expected. -Please refer to the [`test` command documentation](/docs/kyverno-cli/#test) for details. You can also find examples in the [sample policies repo](https://github.com/kyverno/policies). +Please refer to the [`test` command documentation](/docs/kyverno-cli/usage/test/) for details. You can also find examples in the [sample policies repo](https://github.com/kyverno/policies). ## Continuous Integration diff --git a/content/en/docs/Writing policies/external-data-sources.md b/content/en/docs/Writing policies/external-data-sources.md index de21d266d..f689525ee 100644 --- a/content/en/docs/Writing policies/external-data-sources.md +++ b/content/en/docs/Writing policies/external-data-sources.md @@ -207,7 +207,7 @@ kubectl get --raw /api/v1/namespaces/kyverno/pods | kyverno jp query "items | le ``` {{% alert title="Tip" color="info" %}} -Use `kubectl get --raw` and the [`kyverno jp`](/docs/kyverno-cli/#jp) command to test API calls and parse results. +Use `kubectl get --raw` and the [`kyverno jp`](/docs/kyverno-cli/usage/jp/) command to test API calls and parse results. {{% /alert %}} The corresponding API call in Kyverno is defined as below. It uses a variable `{{request.namespace}}` to use the Namespace of the object being operated on, and then applies the same JMESPath to store the count of Pods in the Namespace in the context as the variable `podCount`. Variables may be used in both fields. This new resulting variable `podCount` can then be used in the policy rule. diff --git a/content/en/docs/Writing policies/jmespath.md b/content/en/docs/Writing policies/jmespath.md index ad16b0c48..65d956ac3 100644 --- a/content/en/docs/Writing policies/jmespath.md +++ b/content/en/docs/Writing policies/jmespath.md @@ -219,7 +219,7 @@ spec: image: nginx ``` -Assume this Pod is saved as `pod.yaml` locally, its `containers[]` may be queried using a simple JMESPath expression with help from the [Kyverno CLI](/docs/kyverno-cli/#jp). +Assume this Pod is saved as `pod.yaml` locally, its `containers[]` may be queried using a simple JMESPath expression with help from the [Kyverno CLI](/docs/kyverno-cli/usage/jp/). ```sh $ kyverno jp query -i pod.yaml "spec.containers[]" @@ -343,7 +343,7 @@ spec: In addition to the filters available in the upstream JMESPath library which Kyverno uses, there are also many new and custom filters developed for Kyverno's use found nowhere else. These filters augment the already robust capabilities of JMESPath to bring new functionality and capabilities which help solve common use cases in running Kubernetes. The filters endemic to Kyverno can be used in addition to any of those found in the upstream JMESPath library used by Kyverno and do not represent replaced or removed functionality. -For instructions on how to test these filters in a standalone method (i.e., outside of Kyverno policy), see the [documentation](/docs/kyverno-cli/#jp) on the `kyverno jp` subcommand. +For instructions on how to test these filters in a standalone method (i.e., outside of Kyverno policy), see the [documentation](/docs/kyverno-cli/usage/jp/) on the `kyverno jp` subcommand. Information on each subcommand, its inputs and output, and specific usage instructions can be found below along with helpful and common use cases that have been identified. diff --git a/content/en/docs/Writing policies/validate.md b/content/en/docs/Writing policies/validate.md index fd7d70c32..8c3206e85 100644 --- a/content/en/docs/Writing policies/validate.md +++ b/content/en/docs/Writing policies/validate.md @@ -1703,8 +1703,8 @@ Kubernetes [ValidatingAdmissionPolicy](https://kubernetes.io/docs/reference/acce The Kyverno Command Line Interface (CLI) enables the validation and testing of ValidatingAdmissionPolicies on resources before adding them to a cluster. It can be integrated into CI/CD pipelines to help with the resource authoring process, ensuring that they adhere to the required standards before deployment. Check the below sections for more information: -1. [Apply ValidatingAdmissionPolicies to resources using `kyverno apply`](/docs/kyverno-cli/#applying-validatingadmissionpolicies). -2. [Test ValidatingAdmissionPolicies aganist resources using `kyverno test`](/docs/kyverno-cli/#testing-validatingadmissionpolicies) +1. [Apply ValidatingAdmissionPolicies to resources using `kyverno apply`](/docs/kyverno-cli/usage/apply/#applying-validatingadmissionpolicies). +2. [Test ValidatingAdmissionPolicies aganist resources using `kyverno test`](/docs/kyverno-cli/usage/test/#testing-validatingadmissionpolicies) {{% /alert %}} The ValidatingAdmissionPolicy is designed to perform basic validation checks for an admission request. In contrast, Kyverno is capable of performing complex validation checks, validation across resources with API lookups, mutation, generation, image verification, exception management, reporting, and off-cluster validation. diff --git a/content/en/docs/Writing policies/verify-images/sigstore/_index.md b/content/en/docs/Writing policies/verify-images/sigstore/_index.md index adbb0755d..ab384b899 100644 --- a/content/en/docs/Writing policies/verify-images/sigstore/_index.md +++ b/content/en/docs/Writing policies/verify-images/sigstore/_index.md @@ -435,7 +435,7 @@ This image can now be verified using the leaf or root certificates. ## Keyless signing and verification -The following policy verifies an image signed using ephemeral keys and signing data stored in a transparency log, known as [keyless signing](https://github.com/sigstore/cosign/blob/main/KEYLESS.md): +The following policy verifies an image signed using ephemeral keys and signing data stored in a transparency log, known as [keyless signing](https://docs.sigstore.dev/signing/overview/): ```yaml apiVersion: kyverno.io/v1 diff --git a/lychee.toml b/lychee.toml new file mode 100644 index 000000000..d81766f79 --- /dev/null +++ b/lychee.toml @@ -0,0 +1 @@ +exclude_path = ["public/policies"] \ No newline at end of file