Bring the release-next docs up to date

.spelling

@@ -31,6 +31,7 @@ CSR
 CSRs
 CertificateRequest
 CertificateRequests
+CertificateSecretTemplate
 CertificateSigningRequest
 CertificateSigningRequests
 Changelog

_redirects

@@ -35,3 +35,45 @@ https://cert-manager.io/docs/usage/kubectl-plugin/#status-certificate https://ce
 https://cert-manager.io/docs/usage/kubectl-plugin/#completion https://cert-manager.io/docs/usage/cmctl/#completion
 https://cert-manager.io/docs/usage/kubectl-plugin/#experimental https://cert-manager.io/docs/usage/cmctl/#experimental
 https://cert-manager.io/docs/usage/kubectl-plugin/#certificatesigningrequest https://cert-manager.io/docs/usage/cmctl/#certificatesigningrequest
+
+# docs.cert-manager.io was previously a separately hosted service. The dns has since been redirected and the following rules are required for historical links
+# These rules are in place to capture traffic that is specifically referencing these source urls
+https://docs.cert-manager.io/en/latest/getting-started/index.html https://cert-manager.io/docs/tutorials/
+https://docs.cert-manager.io/en/latest/tutorials/acme/index.html https://cert-manager.io/docs/tutorials/
+https://docs.cert-manager.io/en/latest/ https://cert-manager.io/docs/
+
+# Issuer-specific redirects; these were mined from a wayback machine crawl of the old site:
+# https://web.archive.org/web/20190802192846/http://docs.cert-manager.io/en/latest/tasks/issuers/index.html
+https://docs.cert-manager.io/en/latest/tasks/issuers/setup-acme/http01/* https://cert-manager.io/docs/configuration/acme/http01/
+https://docs.cert-manager.io/en/latest/tasks/issuers/setup-acme/dns01/* https://cert-manager.io/docs/configuration/acme/dns01/
+https://docs.cert-manager.io/en/latest/tasks/issuers/setup-acme/* https://cert-manager.io/docs/configuration/acme/
+https://docs.cert-manager.io/en/latest/tasks/issuers/setup-ca.html https://cert-manager.io/docs/configuration/ca/
+https://docs.cert-manager.io/en/latest/tasks/issuers/setup-selfsigned.html https://cert-manager.io/docs/configuration/selfsigned/
+https://docs.cert-manager.io/en/latest/tasks/issuers/setup-vault.html https://cert-manager.io/docs/configuration/vault/
+https://docs.cert-manager.io/en/latest/tasks/issuers/setup-venafi.html https://cert-manager.io/docs/configuration/venafi/
+
+# fallback in case there are any pages we missed:
+https://docs.cert-manager.io/en/latest/tasks/issuers/* https://cert-manager.io/docs/configuration/
+
+# These rules should capture all historical links that reference endpoints for specfic release versions. Whilst these endpoints might not exist anymore these
+# redirect rules will capture the request and route the user to the specific release-note page
+https://docs.cert-manager.io/en/release-0.1/* https://cert-manager.io/docs/release-notes/release-notes-0.1/ 301!
+https://docs.cert-manager.io/en/release-0.2/* https://cert-manager.io/docs/release-notes/release-notes-0.2/ 301!
+https://docs.cert-manager.io/en/release-0.3/* https://cert-manager.io/docs/release-notes/release-notes-0.3/ 301!
+https://docs.cert-manager.io/en/release-0.4/* https://cert-manager.io/docs/release-notes/release-notes-0.4/ 301!
+https://docs.cert-manager.io/en/release-0.5/* https://cert-manager.io/docs/release-notes/release-notes-0.5/ 301!
+https://docs.cert-manager.io/en/release-0.6/* https://cert-manager.io/docs/release-notes/release-notes-0.6/ 301!
+https://docs.cert-manager.io/en/release-0.7/* https://cert-manager.io/docs/release-notes/release-notes-0.7/ 301!
+https://docs.cert-manager.io/en/release-0.8/* https://cert-manager.io/docs/release-notes/release-notes-0.8/ 301!
+https://docs.cert-manager.io/en/release-0.9/* https://cert-manager.io/docs/release-notes/release-notes-0.9/ 301!
+https://docs.cert-manager.io/en/release-0.10/* https://cert-manager.io/docs/release-notes/release-notes-0.10/ 301!
+https://docs.cert-manager.io/en/release-0.11/* https://cert-manager.io/docs/release-notes/release-notes-0.11/ 301!
+https://docs.cert-manager.io/en/release-0.12/* https://cert-manager.io/docs/release-notes/release-notes-0.12/ 301!
+https://docs.cert-manager.io/en/release-0.13/* https://cert-manager.io/docs/release-notes/release-notes-0.13/ 301!
+https://docs.cert-manager.io/en/release-0.14/* https://cert-manager.io/docs/release-notes/release-notes-0.14/ 301!
+https://docs.cert-manager.io/en/release-0.15/* https://cert-manager.io/docs/release-notes/release-notes-0.15/ 301!
+https://docs.cert-manager.io/en/release-0.16/* https://cert-manager.io/docs/release-notes/release-notes-0.16/ 301!
+# These rules should capture requests to release-notes pages and re-route them accordingly
+https://docs.cert-manager.io/en/release-* https://cert-manager.io/docs/release-notes/release-notes-:splat 301!
+https://docs.cert-manager.io https://cert-manager.io/docs 301!
+https://docs.cert-manager.io/* https://cert-manager.io/docs/:splat 302!

content/en/_index.html

@@ -14,7 +14,7 @@
 		<p class="lead mt-2 display-5">X.509 certificate management for Kubernetes</p>
 		<div class="mx-auto mt-5">
 			<a class="btn btn-lg btn-primary mr-3 mb-4" href="{{< relref "docs" >}}">
-				Learn More <i class="fas fa-arrow-alt-circle-right ml-2"></i>
+				Documentation <i class="fas fa-arrow-alt-circle-right ml-2"></i>
 			</a>
 			<a class="btn btn-lg btn-secondary mr-3 mb-4" href="https://github.com/jetstack/cert-manager">
 				View Repository <i class="fab fa-github ml-2 "></i>

content/en/docs/configuration/acme/dns01/_index.md

@@ -162,6 +162,7 @@ cert-manager also supports out of tree DNS providers using an external webhook.
 Links to these supported providers along with their documentation are below:
 
 - [`AliDNS-Webhook`](https://github.com/pragkent/alidns-webhook)
+- [`cert-manager-alidns-webhook`](https://github.com/DEVmachine-fr/cert-manager-alidns-webhook)
 - [`cert-manager-webhook-civo`](https://github.com/okteto/cert-manager-webhook-civo)
 - [`cert-manager-webhook-dnspod`](https://github.com/qqshfox/cert-manager-webhook-dnspod)
 - [`cert-manager-webhook-dnsimple`](https://github.com/neoskop/cert-manager-webhook-dnsimple)

content/en/docs/configuration/venafi.md

@@ -116,6 +116,24 @@ of the connection parameters are slightly different.
 
 > **Note**: You *must* allow "User Provided CSRs" as part of your TPP policy, as
 > this is the only type supported by cert-manager at this time.
+>
+> More specifically, the valid configurations of the "CSR handling" are:
+>
+> - "User Provided CSRs" selected and unlocked,
+> - "User Provided CSRs" selected and locked,
+> - "Service Generated CSRs" selected and unlocked.
+>
+> When using "Service Generated CSRs" selected and unlocked, the default CSR
+> configuration present in your policy folder will override the configuration of
+> your Certificate resource. The subject DN, key algorithm, and key size will be
+> overridden by the values set in the policy folder.
+>
+> With "Service Generated CSRs" selected and locked, the certificate issuance
+> will systematically fail with the following message:
+>
+> ```plain
+> 400 PKCS#10 data will not be processed. Policy "\VED\Policy\foo" is locked to a Server Generated CSR.
+> ```
 
 In order to set up a Venafi Trust Protection Platform `Issuer`, you must first
 create a Kubernetes `Secret` resource containing your Venafi TPP API

content/en/docs/contributing/release-process.md

@@ -439,15 +439,58 @@ page if a step is missing or if it is outdated.
 
 13. Proceed to the post-release steps:
 
-    1. **(final release only)** Add the new final release to the
-       [supported-releases](/docs/installation/supported-releases/) page.
+    1. **(initial alpha only)** Create a PR on
+       [`cert-manager/release`](https://github.com/cert-manager/release) in
+       order to re-enable the next periodic tests configured in:
 
-    2. **(final release only)** Open a PR to
+       ```plain
+       config/jobs/cert-manager/release-next/cert-manager-release-next-periodics.yaml
+       ```
+
+       Why? Because we disable the "next" periodic tests right after a final release
+       since next periodics are only useful after we do the first alpha (e.g.,
+       in [PR 606](https://github.com/jetstack/testing/pull/606)).
+
+    2. **(initial alpha only)** Open a PR to
+       [`cert-manager/website`](https://github.com/cert-manager/website) in
+       order to:
+
+       - Update the section "How we determine supported Kubernetes versions" on
+         the [supported-releases](/docs/installation/supported-releases/) page.
+         In the table, change the "next periodic" line with the correct links.
+
+    3. **(final release only)** Create a PR on
+       [`cert-manager/release`](https://github.com/cert-manager/release) in
+       order to disable the next periodic tests configured in:
+
+       ```plain
+       config/jobs/cert-manager/release-next/cert-manager-release-next-periodics.yaml
+       ```
+
+       (just remove the file and commit)
+
+       Why? Because that saves us compute time between a final release
+       and the first alpha.
+
+    4. **(final release only)** Open a PR to
+       [`cert-manager/website`](https://github.com/cert-manager/website) in
+       order to:
+
+       - Update the section "Supported releases" in the
+         [supported-releases](/docs/installation/supported-releases/) page.
+       - Update the section "Supported releases" in the
+         [supported-releases](/docs/installation/supported-releases/) page.
+       - Update the section "How we determine supported Kubernetes versions" on
+         the [supported-releases](/docs/installation/supported-releases/) page.
+         In the table, set "n/a" for the line where "next periodic" is since
+         these tests will be disabled until we do our first alpha.
+
+    5. **(final release only)** Open a PR to
        [`jetstack/testing`](https://github.com/jetstack/testing) and change Prow's
        config. To do this, take inspiration from [Maartje's PR
        example](https://github.com/jetstack/testing/pull/397/files).
 
-    3. **(final release only)** Push a new release branch to
+    6. **(final release only)** Push a new release branch to
        [`jetstack/cert-manager`](https://github.com/jetstack/cert-manager). If the
        final release is `v1.0.0`, then push the new branch `release-1.1`:
 
@@ -457,13 +500,13 @@ page if a step is missing or if it is outdated.
         git push origin release-1.1
         ```
 
-    4. **(final release only)** Open a PR to
+    7. **(final release only)** Open a PR to
        [`cert-manager/website`](https://github.com/cert-manager/website) with
        updates to the website configuration. To do this, take inspiration from
        [Maartje's PR
        example](https://github.com/cert-manager/website/pull/309/files).
 
-    5. Ensure that any installation commands in
+    8. Ensure that any installation commands in
        [`cert-manager/website`](https://github.com/cert-manager/website) install
        the latest version. This should be done after every release, including
        patch releases as we want to encourage users to always install the latest

content/en/docs/faq/kubed.md

@@ -33,9 +33,7 @@ spec:
 
 ## Syncing arbitrary secrets across namespaces using kubed
 
-In order for the target Secret to be synced, the Secret resource must first be
-created with the correct annotations before the creation of the Certificate,
-else the Secret will need to be edited instead. The example below shows syncing
+In order for the target Secret to be synced, you can use the `secretTemplate` field for annotating the generated secret with the kubed sync annotation (See [CertificateSecretTemplate]). The example below shows syncing
 a certificate belonging to the `sandbox` Certificate from the `cert-manager`
 namespace, into the `sandbox` namespace.
 
@@ -47,19 +45,6 @@ metadata:
   labels:
     cert-manager-tls: sandbox # Define namespace label for kubed
 ---
-apiVersion: v1
-data:
-  ca.crt: ''
-  tls.crt: ''
-  tls.key: ''
-kind: Secret
-metadata:
-  name: sandbox-tls
-  namespace: cert-manager
-  annotations:
-    kubed.appscode.com/sync: "cert-manager-tls=sandbox" # Sync certificate to matching namespaces
-type: kubernetes.io/tls
----
 apiVersion: cert-manager.io/v1
 kind: Certificate
 metadata:
@@ -72,4 +57,9 @@ spec:
     name: sandbox-ca
     kind: Issuer
     group: cert-manager.io
+  secretTemplate:
+    annotations:
+      kubed.appscode.com/sync: "cert-manager-tls=sandbox" # Sync certificate to matching namespaces
 ```
+
+[CertificateSecretTemplate]: ../../reference/api-docs/#cert-manager.io/v1.CertificateSecretTemplate

content/en/docs/installation/_index.md

@@ -15,7 +15,7 @@ install methods are listed below for each of the situations.
 
 The default static configuration can be installed as follows:
 ```bash
-$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.6.0/cert-manager.yaml
+$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.6.1/cert-manager.yaml
 ```
 More information on this install method [can be found here](./kubectl/).
 

content/en/docs/installation/code-signing.md

@@ -37,9 +37,13 @@ curl -sSL https://cert-manager.io/public-keys/cert-manager-keyring-2021-09-20-10
 helm verify --keyring cert-manager-keyring-2021-09-20-1020CF3C033D4F35BAE1C19E1226061C665DF13E.gpg /path/to/cert-manager-vx.y.z.tgz
 ```
 
-- ASCII-armored signing key: [`cert-manager-pgp-2021-09-20-1020CF3C033D4F35BAE1C19E1226061C665DF13E.asc`](../../../public-keys/cert-manager-pgp-2021-09-20-1020CF3C033D4F35BAE1C19E1226061C665DF13E.asc)
 - GPG keyring: [`cert-manager-keyring-2021-09-20-1020CF3C033D4F35BAE1C19E1226061C665DF13E.gpg`](../../../public-keys/cert-manager-keyring-2021-09-20-1020CF3C033D4F35BAE1C19E1226061C665DF13E.gpg)
 
+If you know what you're doing and you want the signing key in a format that's easy to import into GPG,
+it's available in an ASCII armored version:
+
+- ASCII-armored signing key: [`cert-manager-pgp-2021-09-20-1020CF3C033D4F35BAE1C19E1226061C665DF13E.asc`](../../../public-keys/cert-manager-pgp-2021-09-20-1020CF3C033D4F35BAE1C19E1226061C665DF13E.asc)
+
 ## Container Images / Cosign
 
 Soon, all container images which make up cert-manager will be verifiable using [`cosign`](https://docs.sigstore.dev/cosign/overview).

content/en/docs/installation/helm.md

@@ -46,7 +46,7 @@ or using the `installCRDs` option when installing the Helm chart.
 
 
 ```bash
-$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.6.0/cert-manager.crds.yaml
+$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.6.1/cert-manager.crds.yaml
 ```
 
 ##### Option 2: install CRDs as part of the Helm release
@@ -67,7 +67,7 @@ $ helm install \
   cert-manager jetstack/cert-manager \
   --namespace cert-manager \
   --create-namespace \
-  --version v1.6.0 \
+  --version v1.6.1 \
   # --set installCRDs=true
 ```
 
@@ -80,7 +80,7 @@ $ helm install \
   cert-manager jetstack/cert-manager \
   --namespace cert-manager \
   --create-namespace \
-  --version v1.6.0 \
+  --version v1.6.1 \
   --set prometheus.enabled=false \  # Example: disabling prometheus using a Helm parameter
   --set webhook.timeoutSeconds=4   # Example: changing the wehbook timeout using a Helm parameter
 ```
@@ -97,7 +97,7 @@ $ helm template \
   cert-manager jetstack/cert-manager \
   --namespace cert-manager \
   --create-namespace \
-  --version v1.6.0 \
+  --version v1.6.1 \
   # --set prometheus.enabled=false \   # Example: disabling prometheus using a Helm parameter
   # --set installCRDs=true \           # Uncomment to also template CRDs
   > cert-manager.custom.yaml

content/en/docs/installation/kubectl.md

@@ -21,7 +21,7 @@ are included in a single YAML manifest file:
 Install all cert-manager components:
 
 ```bash
-$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.6.0/cert-manager.yaml
+$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.6.1/cert-manager.yaml
 ```
 
 By default, cert-manager will be installed into the `cert-manager`