diff --git a/content/en/blog/general/introducing-reports-server/index.md b/content/en/blog/general/introducing-reports-server/index.md index fa073b312..ced60974f 100644 --- a/content/en/blog/general/introducing-reports-server/index.md +++ b/content/en/blog/general/introducing-reports-server/index.md @@ -121,10 +121,6 @@ The manifest will install the following components: Reports server comes with a PostgreSQL database, but you may opt for finer control of the database configuration by bringing your own database. See the [database configuration guide](https://github.com/kyverno/reports-server/blob/main/docs/DBCONFIG.md) for more details. -### Migration - -If you already have the PolicyReport CRD installed in your cluster, you will have an existing API service managed by kube-aggregator that sends requests to the Kubernetes API server. You will have to update the existing API service to send request to reports server. See the [migration guide](https://github.com/kyverno/reports-server/blob/main/docs/MIGRATION.md) for more details. - ## Conclusion In this short blog post, we demonstrated how reports server can be used to store policy reports. diff --git a/content/en/blog/general/slsa-3/index.md b/content/en/blog/general/slsa-3/index.md index 045152b79..461f44347 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://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. +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/cosign/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/docs/security/_index.md b/content/en/docs/security/_index.md index b8e4118f6..1267bd329 100644 --- a/content/en/docs/security/_index.md +++ b/content/en/docs/security/_index.md @@ -62,7 +62,7 @@ With each release, the following artifacts are uploaded (where CLI binaries incl ## Verifying Kyverno Container Images -Kyverno container images are signed using Cosign and the [keyless signing feature](https://docs.sigstore.dev/cosign/verify/). The signatures are stored in a separate repository from the container image they reference located at `ghcr.io/kyverno/signatures`. To verify the container image using Cosign v1.x, follow the steps below. +Kyverno container images are signed using Cosign and the [keyless signing feature](https://docs.sigstore.dev/cosign/verifying/verify/). The signatures are stored in a separate repository from the container image they reference located at `ghcr.io/kyverno/signatures`. To verify the container image using Cosign v1.x, follow the steps below. 1. Install [Cosign](https://github.com/sigstore/cosign#installation) 2. Configure the Kyverno signature repository: 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 0f700de58..bdb31dcbf 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://docs.sigstore.dev/signing/overview/): +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/cosign/signing/overview/): ```yaml apiVersion: kyverno.io/v1 @@ -508,7 +508,7 @@ The supported formats include: * gcpkms://projects/[PROJECT]/locations/global/keyRings/[KEYRING]/cryptoKeys/[KEY] * hashivault://[KEY] -Refer to https://docs.sigstore.dev/cosign/kms_support for additional details. +Refer to https://docs.sigstore.dev/cosign/key_management/overview/ for additional details. ### Enabling IRSA to access AWS KMS