diff --git a/.spelling b/.spelling index 461dbe15501..17697568cc2 100644 --- a/.spelling +++ b/.spelling @@ -31,6 +31,7 @@ CSR CSRs CertificateRequest CertificateRequests +CertificateSecretTemplate CertificateSigningRequest CertificateSigningRequests Changelog diff --git a/_redirects b/_redirects index 557a9971b8f..21d1045ad21 100644 --- a/_redirects +++ b/_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! diff --git a/content/en/_index.html b/content/en/_index.html index ed8c80ada1d..7e4615434da 100644 --- a/content/en/_index.html +++ b/content/en/_index.html @@ -14,7 +14,7 @@

X.509 certificate management for Kubernetes

}}"> - Learn More + Documentation View Repository diff --git a/content/en/docs/configuration/acme/dns01/_index.md b/content/en/docs/configuration/acme/dns01/_index.md index d2ba62fe55f..913a6a68920 100644 --- a/content/en/docs/configuration/acme/dns01/_index.md +++ b/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) diff --git a/content/en/docs/configuration/venafi.md b/content/en/docs/configuration/venafi.md index 5160050d711..63ba14474b0 100644 --- a/content/en/docs/configuration/venafi.md +++ b/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 diff --git a/content/en/docs/contributing/release-process.md b/content/en/docs/contributing/release-process.md index 32eda3ca016..fb41ed6df16 100644 --- a/content/en/docs/contributing/release-process.md +++ b/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 diff --git a/content/en/docs/faq/kubed.md b/content/en/docs/faq/kubed.md index fff6953d170..c8ecaab3301 100644 --- a/content/en/docs/faq/kubed.md +++ b/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 \ No newline at end of file diff --git a/content/en/docs/installation/_index.md b/content/en/docs/installation/_index.md index ce516eec827..995e6120a09 100644 --- a/content/en/docs/installation/_index.md +++ b/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/). diff --git a/content/en/docs/installation/code-signing.md b/content/en/docs/installation/code-signing.md index e0e86921efa..c2969e7458e 100644 --- a/content/en/docs/installation/code-signing.md +++ b/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). diff --git a/content/en/docs/installation/helm.md b/content/en/docs/installation/helm.md index 989f0730bf3..a124b2da973 100644 --- a/content/en/docs/installation/helm.md +++ b/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 diff --git a/content/en/docs/installation/kubectl.md b/content/en/docs/installation/kubectl.md index 6791886ff56..819be78bd51 100644 --- a/content/en/docs/installation/kubectl.md +++ b/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` diff --git a/content/en/docs/installation/supported-releases.md b/content/en/docs/installation/supported-releases.md index d040e460ef6..3781589e8d9 100644 --- a/content/en/docs/installation/supported-releases.md +++ b/content/en/docs/installation/supported-releases.md @@ -12,22 +12,22 @@ Inspired by https://istio.io/latest/about/supported-releases/ This page lists the status, timeline and policy for currently supported releases. -Each release is supported for a period of four months, and we create a new +Each release is supported for a period of four months, and we aim to create a new release every two months. ## Supported releases {#supported-releases} -| Release | Release Date | End of life | [Supported Kubernetes versions][s] | [Supported OpenShift versions][s] | -|---------|:------------:|:-----------:|:----------------------------------------:|:---------------------------------:| -| [1.6][] | Oct 26, 2021 | Feb 9, 2022 | 1.16, 1.17, 1.18, 1.19, 1.20, 1.21, 1.22 | 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9 | -| [1.5][] | Aug 11, 2021 | Dec 7, 2021 | 1.16, 1.17, 1.18, 1.19, 1.20, 1.21, 1.22 | 4.3, 4.4, 4.5, 4.6, 4.7, 4.8 | +| Release | Release Date | End of Life | [Supported Kubernetes versions][s] | [Supported OpenShift versions][s] | +|---------|:------------:|:------------:|:----------------------------------:|:---------------------------------:| +| [1.6][] | Oct 26, 2021 | Mar 30, 2022 | 1.17 → 1.22 | 4.4 → 4.9 | +| [1.5][] | Aug 11, 2021 | Jan 26, 2022 | 1.16 → 1.22 | 4.3 → 4.8 | ## Upcoming releases | Release | Release Date | End of life | [Supported Kubernetes versions][s] | [Supported OpenShift versions][s] | |---------|:------------:|:------------:|:----------------------------------:|:---------------------------------:| -| [1.7][] | Dec 7, 2021 | Apr 6, 2022 | to be defined | to be defined | -| 1.8 | Feb 9, 2022 | June 8, 2022 | to be defined | to be defined | +| [1.7][] | Jan 26, 2022 | May 26, 2022 | 1.18 → 1.23 | 4.5 → 4.9 | +| 1.8 | Mar 30, 2022 | June 8, 2022 | To be confirmed | To be confirmed | Note that dates in the future are uncertain and might change. @@ -183,15 +183,21 @@ The list of supported Kubernetes versions displayed in the [Supported Releases](#supported-releases) section depends on what the cert-manager maintainers think is reasonable to support and to test. -Our testing coverage is: +As of 16 Dec 2021, our testing coverage is: + +| Release branch | Prow configuration | Dashboard | Kubernetes versions tested | Periodicity | +|:--------------:|:------------------------------|:--------------------------|:--------------------------:|:-------------:| +| PRs | [`presubmits.yaml`][] | [`presubmits-blocking`][] | 1.22 | On each PR | +| master | [`periodics.yaml`][] | [`master`][] | 1.18 → 1.23 | Every 2 hours | +| release-1.7 | n/a\* | n/a | n/a | n/a | +| release-1.6 | [`previous-periodics.yaml`][] | [`previous`][] | 1.18 → 1.23 | Every 2 hours | +| release-1.5 | n/a | | n/a | n/a | -| Release branch | Prow configuration | Dashboard | Kubernetes versions tested | Periodicity | -| :------------: | :---------------------------- | :------------------------ | :-------------------------: | :-----------: | -| PRs | [`presubmits.yaml`][] | [`presubmits-blocking`][] | 1.22 | On each PR | -| master | [`periodics.yaml`][] | [`master`][] | 1.16 → 1.22 | Every 2 hours | -| release-1.6 | [`next-periodics.yaml`][] | [`next`][] | 1.16 → 1.22 | Every 2 hours | -| release-1.5 | [`previous-periodics.yaml`][] | [`previous`][] | 1.16 → 1.22 | Every 2 hours | -| release-1.4 | N/A | | N/A | N/A | +\*The release-1.7 is currently equal to release-1.6; we decided to disable the +periodic tests until we release `1.7.0-alpha.0`. The disabling of the periodic +tests was performed in the [testing PR +606](https://github.com/jetstack/testing/pull/606). This note should be removed +as soon as we release `1.7.0-alpha.0`. [`presubmits.yaml`]: https://github.com/jetstack/testing/blob/master/config/jobs/cert-manager/cert-manager-presubmits.yaml [`periodics.yaml`]: https://github.com/jetstack/testing/blob/master/config/jobs/cert-manager/cert-manager-periodics.yaml @@ -207,12 +213,12 @@ to be supporting most commercial Kubernetes offerings. | Vendor | Oldest Kubernetes Release\* | Other Old\*\* Kubernetes Releases | |:-----------------:|-----------------------------|---------------------------------------------------------------| -| [EKS][eks] | 1.16 (EOL Sep 2021) | 1.17 (EOL Nov 2021), 1.18 (EOL Dec 2021), 1.19 (EOL Apr 2022) | -| [GKE][gke] | 1.17 (EOL Nov 2021) | 1.18 (EOL Mar 2022), 1.19 (EOL Jun 2022) | -| [AKS][aks] | 1.18 (EOL Jul 2021) | 1.19 (EOL Aug 2021) | +| [EKS][eks] | 1.18 (EOL Feb 2022) | 1.19 (EOL Apr 2022), 1.20 (EOL Jul 2022) | +| [GKE][gke] | 1.18 (EOL Mar 2022) | 1.19 (EOL Jun 2022), 1.20 (EOL Aug 2022) | +| [AKS][aks] | 1.19 (EOL Jan 2022) | 1.20 (EOL Feb 2022) | | [OpenShift 4][os] | 1.18 (4.5, EOL July 2021) | 1.19 (4.6 EUS, EOL May 2022) | -\*As of July 30, 2021. +\*Oldest release relevant to the next cert-manager release, as of 2021-11-19 \*\*We say that a Kubernetes offering is "old" when it is not supported upstream as per the [Version Skew diff --git a/content/en/docs/installation/upgrading/remove-deprecated-apis.md b/content/en/docs/installation/upgrading/remove-deprecated-apis.md index 8ff989eba3b..ae366d89051 100644 --- a/content/en/docs/installation/upgrading/remove-deprecated-apis.md +++ b/content/en/docs/installation/upgrading/remove-deprecated-apis.md @@ -14,9 +14,7 @@ We have deprecated the following cert-manager APIs: - `acme.cert-manager.io/v1alpha3` - `acme.cert-manager.io/v1beta1` -These APIs will be removed in cert-manager `v1.6.0`. -If you have a cert-manager installation that is using or has previously used these deprecated APIs you may need to upgrade your cert-manager custom resources and CRDs. This needs to be done before upgrading to cert-manager `v1.6.0`. - +These APIs were removed in cert-manager `v1.6.0`. If you have a cert-manager installation that is using or has previously used these deprecated APIs you'll need to upgrade your cert-manager custom resources and CRDs. This needs to be done before upgrading to cert-manager `v1.6.0`. ## Upgrading existing cert-manager resources diff --git a/content/en/docs/installation/upgrading/upgrading-0.7-0.8.md b/content/en/docs/installation/upgrading/upgrading-0.7-0.8.md index f029932ba50..8e395a84884 100644 --- a/content/en/docs/installation/upgrading/upgrading-0.7-0.8.md +++ b/content/en/docs/installation/upgrading/upgrading-0.7-0.8.md @@ -94,7 +94,7 @@ spec: dns01: # Adjust the configuration below according to your environment. # You can view more example configurations for different DNS01 - # providers in the documentation: https://docs.cert-manager.io/en/latest/tasks/issuers/setup-acme/dns01/index.html + # providers in the documentation: https://cert-manager.io/docs/tutorials/acme/dns-validation/ cloudflare: email: my-cloudflare-acc@example.com apiKeySecretRef: @@ -220,7 +220,7 @@ spec: dns01: # Adjust the configuration below according to your environment. # You can view more example configurations for different DNS01 - # providers in the documentation: https://docs.cert-manager.io/en/latest/tasks/issuers/setup-acme/dns01/index.html + # providers in the documentation: https://cert-manager.io/docs/tutorials/acme/dns-validation/ cloudflare: email: my-cloudflare-acc@example.com apiKeySecretRef: diff --git a/content/en/docs/installation/upgrading/upgrading-1.5-1.6.md b/content/en/docs/installation/upgrading/upgrading-1.5-1.6.md new file mode 100644 index 00000000000..b6e85d89cec --- /dev/null +++ b/content/en/docs/installation/upgrading/upgrading-1.5-1.6.md @@ -0,0 +1,29 @@ +--- +title: "Upgrading from v1.5 to v1.6" +linkTitle: "v1.5 to v1.6" +weight: 760 +type: "docs" +--- + +### Upgrading cert-manager CRDs and stored versions of cert-manager custom resources + +Following their deprecation in version 1.4, the cert-manager API versions `v1alpha2, v1alpha3, and v1beta1` are no longer served. + +This means if your deployment manifests contain any of these API versions, you will not be able to deploy them after upgrading. +Our new `cmctl` utility or old `kubectl cert-manager` plugin can [convert](../../../usage/cmctl/#convert) old manifests to `v1` for you. + +{{% pageinfo color="warning" %}} + +⛔️ If you are upgrading cert-manager on a cluster which has previously had +cert-manager < `v1.0.0`, you will need to ensure that all cert-manager custom +resources are stored in `etcd` at `v1` version and that cert-manger CRDs do not +reference the deprecated APIs **before you upgrade to `v1.6`**. + +This is explained in more detail in the [Upgrading existing cert-manager resources](../remove-deprecated-apis/#upgrading-existing-cert-manager-resources) +page. + +{{% /pageinfo %}} + +## Now Follow the Regular Upgrade Process + +From here on you can follow the [regular upgrade process](../). diff --git a/content/en/docs/release-notes/release-notes-0.11.md b/content/en/docs/release-notes/release-notes-0.11.md index 45c4cac623d..bf00060d5ba 100644 --- a/content/en/docs/release-notes/release-notes-0.11.md +++ b/content/en/docs/release-notes/release-notes-0.11.md @@ -47,7 +47,7 @@ The changes to our CRD resources mean that upgrading requires more manual intervention than in previous releases. It's recommended that you backup and completely [uninstall -cert-manager](https://docs.cert-manager.io/en/release-0.12/tasks/uninstall/) +cert-manager](https://cert-manager.io/docs/installation/uninstall/) before re-installing the `v0.11` release. You will also need to manually update all your backed up cert-manager resource diff --git a/content/en/docs/release-notes/release-notes-0.9.md b/content/en/docs/release-notes/release-notes-0.9.md index 04641f0c2dc..1d0c47d2062 100644 --- a/content/en/docs/release-notes/release-notes-0.9.md +++ b/content/en/docs/release-notes/release-notes-0.9.md @@ -64,7 +64,7 @@ out of tree issuer will follow in later releases. You can read more on the motivations and road map in the [enhancement proposal](https://github.com/jetstack/cert-manager/blob/master/design/20190708.certificate-request-crd.md) or how this resource is used in the -[docs](https://docs.cert-manager.io/en/release-0.9/reference/certificaterequests.html). +[docs](https://cert-manager.io/docs/concepts/certificaterequest/). ### DNS Zones support for ACME challenge solver selector diff --git a/content/en/docs/release-notes/release-notes-1.6.md b/content/en/docs/release-notes/release-notes-1.6.md index cd099b0c5b2..506983021f7 100644 --- a/content/en/docs/release-notes/release-notes-1.6.md +++ b/content/en/docs/release-notes/release-notes-1.6.md @@ -9,19 +9,35 @@ type: "docs" ### Legacy cert-manager API versions are no-longer served -Following their deprecation in version 1.5, the cert-manager API versions `v1alpha2, v1alpha3, and v1beta1` are no longer served. +Following their deprecation in version 1.4, the cert-manager API versions `v1alpha2, v1alpha3, and v1beta1` are no longer served. -This means if your deployment manifests contain any of these API versions, you will not be able to deploy them after upgrading. Our new `cmctl` utility or old `kubectl cert-manager` plugin can [convert](https://cert-manager.io/docs/usage/kubectl-plugin/#convert) old manifests to `v1` for you. +This means if your deployment manifests contain any of these API versions, you will not be able to deploy them after upgrading. Our new `cmctl` utility or old `kubectl cert-manager` plugin can [convert](../../usage/cmctl/#convert) old manifests to `v1` for you. + +{{% pageinfo color="warning" %}} + +⛔️ If you are upgrading cert-manager on a cluster which has previously had +cert-manager < `v1.0.0`, you will need to ensure that all cert-manager custom +resources are stored in `etcd` at `v1` version and that cert-manger CRDs do not +reference the deprecated APIs **before you upgrade to `v1.6`**. + +This is explained in more detail in the [Upgrading existing cert-manager resources](../../installation/upgrading/remove-deprecated-apis/#upgrading-existing-cert-manager-resources) +page. + +{{% /pageinfo %}} ### JKS Keystore Minimum Password Length -[JKS Keystores][jks-keystore] now have a minimum password length of 6 characters, +ℹ️ This no longer applies as it was fixed in `v1.6.1`, but will remain here for +informational purposes. If you haven't upgraded cert-manager to `v1.6.0` from any `v1.5` +release, we recommend upgrading straight to the latest version, skipping `v1.6.0`. + +In cert-manager `v1.6.0` [JKS Keystores][jks-keystore] had a minimum password length of 6 characters, as an unintended side effect of [upgrading keystore-go from `v2` to `v4`][jks-keystore-upgrade-pr]. -If you are using a shorter password, certificates will fail to renew, -and the only observable error will be in the cert-manager logs. -We are discussing the best remediation for a future `v1.6.1` release. +If you are using a shorter password, certificates would have failed to renew, +and the only observable error was in the cert-manager logs. +This was fixed in cert-manager `v1.6.1`. -[jks-keystore]: https://cert-manager.io/docs/reference/api-docs/#cert-manager.io/v1.CertificateKeystores +[jks-keystore]: ../../reference/api-docs/#cert-manager.io/v1.CertificateKeystores [jks-keystore-upgrade-pr]: https://github.com/jetstack/cert-manager/pull/4428 ## Major Themes diff --git a/content/en/docs/tutorials/_index.md b/content/en/docs/tutorials/_index.md index 5ff45a145d5..dedf6cb860e 100644 --- a/content/en/docs/tutorials/_index.md +++ b/content/en/docs/tutorials/_index.md @@ -25,6 +25,7 @@ for you to learn from. Take a look! ### External Tutorials +- A great AWS blog post on using cert-manager for end-to-end encryption in EKS. See [Setting up end-to-end TLS encryption on Amazon EKS](https://aws.amazon.com/blogs/containers/setting-up-end-to-end-tls-encryption-on-amazon-eks-with-the-new-aws-load-balancer-controller/) - A full cert-manager installation demo on a GKE Cluster. See [How-To: Automatic SSL Certificate Management for your Kubernetes Application Deployment](https://medium.com/contino-engineering/how-to-automatic-ssl-certificate-management-for-your-kubernetes-application-deployment-94b64dfc9114) - cert-manager installation on GKE Cluster using Workload Identity. See [Kubernetes, ingress-nginx, cert-manager & external-dns](https://blog.atomist.com/kubernetes-ingress-nginx-cert-manager-external-dns/) - A video tutorial for beginners showing cert-manager in action. See [Free SSL for Kubernetes with cert-manager](https://www.youtube.com/watch?v=hoLUigg4V18) diff --git a/content/en/docs/tutorials/acme/dns-validation.md b/content/en/docs/tutorials/acme/dns-validation.md index d92065d54be..20c74553980 100644 --- a/content/en/docs/tutorials/acme/dns-validation.md +++ b/content/en/docs/tutorials/acme/dns-validation.md @@ -44,7 +44,7 @@ spec: dns01: cloudDNS: # The ID of the GCP project - # reference: https://docs.cert-manager.io/en/latest/tasks/issuers/setup-acme/dns01/google.html + # reference: https://cert-manager.io/docs/tutorials/acme/dns-validation/ project: $PROJECT_ID # This is the secret used to access the service account serviceAccountSecretRef: diff --git a/content/en/docs/tutorials/acme/ingress.md b/content/en/docs/tutorials/acme/ingress.md index 8554f0d4393..3a3b95045c7 100644 --- a/content/en/docs/tutorials/acme/ingress.md +++ b/content/en/docs/tutorials/acme/ingress.md @@ -644,7 +644,7 @@ Events: > Note: If your challenges are not becoming 'valid' and remain in the 'pending' > state (or enter into a 'failed' state), it is likely there is some kind of > configuration error. Read the [Challenge resource reference -> docs](../../../reference/api-docs/#acme.cert-manager.io/v1alpha2.Challenge) for more +> docs](../../../reference/api-docs/#acme.cert-manager.io/v1.Challenge) for more > information on debugging failing challenges. Once the challenge(s) have been completed, their corresponding challenge diff --git a/content/en/docs/usage/certificate.md b/content/en/docs/usage/certificate.md index 41325e9bd3b..4ed495fbcda 100644 --- a/content/en/docs/usage/certificate.md +++ b/content/en/docs/usage/certificate.md @@ -119,7 +119,7 @@ The `Certificate` will be issued using the issuer named `ca-issuer` in the > days, 23 hours (the _full duration_ remains 90 days). A full list of the fields supported on the Certificate resource can be found in -the [API reference documentation](../../reference/api-docs/#cert-manager.io/v1alpha2.CertificateSpec). +the [API reference documentation](../../reference/api-docs/#cert-manager.io/v1.CertificateSpec). ## X.509 key usages and extended key usages {#key-usages} @@ -136,7 +136,7 @@ cert-manager will not attempt to request a new certificate if the current certificate does not match the current key usage set. An exhaustive list of supported key usages can be found in the [API reference -documentation](../../reference/api-docs/#cert-manager.io/v1alpha2.KeyUsage). +documentation](../../reference/api-docs/#cert-manager.io/v1.KeyUsage). ## Temporary Certificates while Issuing {#temporary-certificates-whilst-issuing} diff --git a/scripts/gendocs/generate b/scripts/gendocs/generate index 9a150701e84..d48a566fbf6 100755 --- a/scripts/gendocs/generate +++ b/scripts/gendocs/generate @@ -45,7 +45,7 @@ GOROOT="$(go env GOROOT)" export GOROOT GOBIN="${tmpdir}/bin" export GOBIN -go get github.com/ahmetb/gen-crd-api-reference-docs@v0.2.0 +go get github.com/ahmetb/gen-crd-api-reference-docs@v0.3.0 mkdir -p "${GOPATH}/src/github.com/jetstack" gitdir="${GOPATH}/src/github.com/jetstack/cert-manager" @@ -53,9 +53,16 @@ echo "+++ Cloning cert-manager repository..." git clone "https://github.com/jetstack/cert-manager.git" "$gitdir" cd "$gitdir" +# genversion takes two arguments (branch in cert-manager repo and a directory in +# this repo under content/en) and generates API reference docs from cert-manager +# branch for the path in this repo. genversion() { + checkout "$1" + gendocs "$2" +} + +checkout() { branch="$1" - outputdir="$2" pushd "$gitdir" rm -rf vendor/ echo "+++ Checking out branch $branch" @@ -63,6 +70,9 @@ genversion() { git reset --hard "origin/$branch" echo "+++ Running 'go mod vendor' (this may take a while)" go mod vendor +} +gendocs() { + outputdir="$1" echo "+++ Generating reference docs..." "${GOBIN}/gen-crd-api-reference-docs" \ -config "${REPO_ROOT}/scripts/gendocs/config.json" \ @@ -73,12 +83,32 @@ genversion() { rm -rf vendor/ popd } - # The branches named here exist in the `jetstack/cert-manager` repo. genversion "release-1.7" "next-docs" -genversion "release-1.6" "docs" -genversion "release-1.6" "v1.6-docs" + +# In cert-manager 1.6 cert-manager.io and acme.cert-manager.io alpha and beta +# API versions are no longer served, but the apis are still in the codebase. We +# don't want to show the docs for those API versions so this is a workaround. +# This will only be necessary for the release-1.6 branch. +checkout "release-1.6" +rm -r pkg/apis/acme/v1alpha2 +rm -r pkg/apis/acme/v1alpha3 +rm -r pkg/apis/acme/v1beta1 +rm -r pkg/apis/certmanager/v1alpha2 +rm -r pkg/apis/certmanager/v1alpha3 +rm -r pkg/apis/certmanager/v1beta1 +gendocs "docs" + +checkout "release-1.6" +rm -r pkg/apis/acme/v1alpha2 +rm -r pkg/apis/acme/v1alpha3 +rm -r pkg/apis/acme/v1beta1 +rm -r pkg/apis/certmanager/v1alpha2 +rm -r pkg/apis/certmanager/v1alpha3 +rm -r pkg/apis/certmanager/v1beta1 +gendocs "v1.6-docs" + genversion "release-1.5" "v1.5-docs" genversion "release-1.4" "v1.4-docs" genversion "release-1.3" "v1.3-docs"