Replicate PR 446 from kubewarden community docs -> kubewarden/docs#446

Signed-off-by: John Krug <[email protected]>
jhkrug · Sep 11, 2024 · 42472e8 · 42472e8
1 parent ac9fadf
commit 42472e8
Show file tree

Hide file tree

Showing 9 changed files with 63 additions and 75 deletions.
diff --git a/docs/next/modules/en/nav.adoc b/docs/next/modules/en/nav.adoc
@@ -53,13 +53,14 @@
 ** xref:tutorials/publish-policy-to-artifact-hub.adoc[]
 * Explanations
 ** xref:explanations/mutating-policies.adoc[]
+** xref:explanations/context-aware-policies.adoc[]
+** xref:explanations/certificates.adoc[]
 ** xref:explanations/distributing-policies.adoc[]
 ** Comparisons
 *** xref:explanations/comparisons/opa-comparison.adoc[]
 ** xref:explanations/audit-scanner/audit-scanner.adoc[]
 *** xref:explanations/audit-scanner/limitations.adoc[]
 *** xref:explanations/audit-scanner/policy-reports.adoc[]
-*** xref:explanations/context-aware-policies.adoc[]
 ** xref:explanations/architecture.adoc[]
 * Howtos
 ** xref:howtos/tasks.adoc[]

diff --git a/docs/next/modules/en/pages/explanations/certificates.adoc b/docs/next/modules/en/pages/explanations/certificates.adoc
@@ -0,0 +1,50 @@
+= Certificate rotation
+:description: How Kubewarden controller manages its certificates
+:doc-persona: ["kubewarden-operator"]
+:doc-topic: ["explanations", "certificates"]
+:doc-type: ["explanation"]
+:keywords: ["kubewarden", "certificate", "controller", "reconciliation"]
+:sidebar_label: Certificate rotation
+:sidebar_position: 21
+
+Since Kubewarden v1.17.0, the cert-manager dependency was removed. The
+controller is able to manage all the certificates used by all the components.
+This means that the controller has a new reconciliation loop that ensures the
+certificates are always up-to-date and the webhook configuration is correct.
+
+The first certificate generation is done by the Helm chart installation. It
+will generate the root CA with ten years until expiration. The Helm chart
+installation also generates the controller webhook webserver certificate,
+signed by the root CA. This is used by the API server to communicate with the
+Kubewarden controller to validate the CRDs. It has a one year expiration.
+
+Once the controller starts, its reconciler renews the certificates
+automatically when they are about to expire. It also updates all the
+certificates and webhook configurations used by the entire Kubewarden stack.
+
+[NOTE]
+====
+All the certificates generated by the Helm chart and later by the controller uses
+ECDSA P256 keys.
+====
+
+
+The reconciliation loop renews certificates 60 days before expiration. The
+certificates are rotated without downtime.
+The reconciliation loop takes care of renewing the root CA too. 60 days before
+its expiration, a new root CA is generated and the CA bundled used by all the
+webhooks is updated with one that includes both the new root CA and
+the old one.
+The change of the root CA leads the reconciler to recreate the certificates
+issued to the webhooks.
+The propagation of the new certificates requires some time. However during this
+time the updated CA bundle allows the API server to continue to communicate
+with all the webhooks without any downtime.
+
+Once the new certificate is ready and the old one is invalid, the controller
+will update the CA bundle used by the webhooks to include only the latest root CA.
+
+When a policy server certificate or the controller webserver certificate is
+renewed, the controller updates the secret with the new certificate signed by
+the root CA. Due to this reload feature, the controller, and the policy server,
+use the new certificate with no need to restart processes, hence no downtime.
diff --git a/docs/next/modules/en/pages/howtos/Rancher-Fleet.adoc b/docs/next/modules/en/pages/howtos/Rancher-Fleet.adoc
@@ -17,8 +17,7 @@ It does this by defining https://fleet.rancher.io/concepts[Fleet Bundles].
 == Installing
 
 The Kubewarden charts are standard charts,
-they have dependencies (such as `cert-manager`),
-and depend transitively on each other
+they depend transitively on each other:
 
 `kubewarden-crds` ← `kubewarden-controller` ← `kubewarden-defaults`
 

diff --git a/docs/next/modules/en/pages/howtos/airgap/02-install.adoc b/docs/next/modules/en/pages/howtos/airgap/02-install.adoc
@@ -31,18 +31,6 @@ Optionally, you can verify the signatures of the
 +
 ====
 
-
-. Add `cert-manager`, if not available, to your private registry.
-+
-[subs="+attributes",console]
-----
- helm repo add jetstack https://charts.jetstack.io
- helm repo update
- helm pull jetstack/cert-manager
- helm template ./cert-manager-<Version>.tgz | \
-   awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./kubewarden-images.txt
-----
-
 . Download `kubewarden-save-images.sh` and `kubewarden-load-images.sh` from the
 https://github.com/kubewarden/utils[utilities repository].
 . Save Kubewarden container images into a `.tar.gz` file:
@@ -86,13 +74,6 @@ helm pull kubewarden/kubewarden-controller
 helm pull kubewarden/kubewarden-defaults
 ----
 
-Download `cert-manager`, if not installed, to the air gap cluster.
-
-[subs="+attributes",shell]
-----
-helm pull jetstack/cert-manager
-----
-
 == Populate private registry
 
 Move these files to the air gap environment:
@@ -143,23 +124,12 @@ in the documentation to learn about configuring the `sources.yaml` file
 
 == Install Kubewarden
 
-Now that your private registry has everything required you can install Kubewarden.
-The only difference to a standard Kubewarden installation is that you need to change the registry in the container images and policies to be the private registry.
-
-Install `cert-manager`, if not already installed, in the air gap cluster:
-
-[subs="+attributes",shell]
-----
-helm install --create-namespace cert-manager ./cert-manager-<Version>.tgz \
-    -n kubewarden \
-    --set crds.enabled=true \
-    --set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/jetstack/cert-manager-controller \
-    --set webhook.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/jetstack/cert-manager-webhook \
-    --set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/jetstack/cert-manager-cainjector \
-    --set startupapicheck.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/jetstack/cert-manager-ctl
-----
+Now that your private registry has everything required you can install
+Kubewarden.  The only difference to a standard Kubewarden installation is that
+you need to change the registry in the container images and policies to be the
+private registry.
 
-Now install the Kubewarden stack:
+Install the Kubewarden stack:
 
 [subs="+attributes",shell]
 ----

diff --git a/docs/next/modules/en/pages/howtos/telemetry/20-tracing-qs.adoc b/docs/next/modules/en/pages/howtos/telemetry/20-tracing-qs.adoc
@@ -92,8 +92,7 @@ We can proceed to the deployment of Kubewarden in the usual way.
 
 [NOTE]
 ====
-cert-manager is a requirement of Kubewarden, and OpenTelemetry is required for this
-feature, but we've already installed them in a previous section of this book.
+cert-manager is a requirement of OpenTelemetry, but we've already installed it in a previous section of this book.
 ====
 
 

diff --git a/docs/next/modules/en/pages/howtos/telemetry/30-metrics-qs.adoc b/docs/next/modules/en/pages/howtos/telemetry/30-metrics-qs.adoc
@@ -100,8 +100,8 @@ We can now install Kubewarden in the recommended way with Helm charts.
 
 [NOTE]
 ====
-cert-manager is a requirement of Kubewarden, and OpenTelemetry is required for this
-feature, but we've already installed them in a previous section of this book.
+cert-manager is a requirement of OpenTelemetry,
+but we've already installed it in a previous section of this book.
 ====
 
 

diff --git a/docs/next/modules/en/pages/quick-start.adoc b/docs/next/modules/en/pages/quick-start.adoc
@@ -11,7 +11,7 @@ include::partial$kw-global.adoc[]
 
 The Kubewarden stack comprises:
 
-* Some {cluster-admission-policy} resources: this is how policies are defined for Kubernetes clusters
+* Some {cluster-admission-policy} resoit: this is how policies are defined for Kubernetes clusters
 * Some {policy-server} resources: representing a deployment of a Kubewarden
 `PolicyServer`. Your administrator's policies are loaded and evaluated by the Kubewarden
 `PolicyServer`
@@ -29,23 +29,6 @@ The Kubernetes Custom Resource Definitions (CRDs) defined by Kubewarden are desc
 
 == Installation
 
-[IMPORTANT]
-.Prerequisites
-====
-The Helm chart depends on `cert-manager`. Ensure you install https://cert-manager.io/docs/installation/[`cert-manager`] _before_ the `kubewarden-controller` chart.
-
-You can install the latest version of `cert-manager` through Helm by running the following commands:
-
-[subs="+attributes",console]
-----
-helm repo add jetstack https://charts.jetstack.io
-
-helm install --wait --namespace cert-manager --create-namespace \
-	--set crds.enabled=true cert-manager jetstack/cert-manager
-----
-====
-
-
 [IMPORTANT]
 .Authentication
 ====

diff --git a/docs/next/modules/en/pages/reference/dependency-matrix.adoc b/docs/next/modules/en/pages/reference/dependency-matrix.adoc
@@ -20,20 +20,6 @@ backwards-incompatible changes still happen. Kubewarden devs do their best to
 track Opentelemetry stack changes and adjust to them. Kubewarden is tested against a known working
 range of Opentelemetry, metrics and tracing stack.
 
-== Hard dependencies
-
-Needed for Kubewarden deployments.
-
-[cols=",^,^,^"]
-|===
-| Chart dependency | Helm chart `appVersion` | Helm chart `version` | Comments
-
-| `jetstack/cert-manager` chart
-| `≥ 1.13 < 2`
-| Example: `v1.13.2`
-| Plans to make optional
-|===
-
 == Optional dependencies
 
 Needed for specific features.

diff --git a/docs/next/modules/en/pages/reference/threat-model.adoc b/docs/next/modules/en/pages/reference/threat-model.adoc
@@ -279,7 +279,7 @@ For example, by:
 * using unsigned and malicious images for:
  ** Kubewarden-controller
  ** policy-server
- ** any of the Kubewarden dependencies (cert-manager)
+ ** any of the Kubewarden dependencies
  ** any optional dependencies (Grafana, Prometheus, and others)
 * by compromising the Helm charts payload