cert-manager / website

Source code for the cert-manager.io website, including project documentation

cert-manager Website

Source code for the cert-manager.io website, which includes documentation for each version of cert-manager as well as supported version information, installation instructions, tutorials, guides, FAQs and information for contributors.

The site uses next.js as a framework, and all documentation is written in MDX (Markdown).

Development Requirements

At the very least, you'll need to install a couple of tools to be able to build and run the site locally and to test your changes.

The following tool(s) must be installed on your system prior to developing the website:

• cURL
• NodeJS, version 16+
• Golang, version 1.17+

We also assume you've got GNU coreutils installed, which is usually the case by default on Linux and should be installable via Homebrew on macOS.

Website Development Guides

Which branch should I use?

There are two relevant branches used for website development: master and release-next.

Changes to master will be reflected on the live website shortly after they're merged. If your change is relevant to any version of cert-manager which has already been released, your change likely needs to be made against master.

release-next is used for features which haven't been released in a stable version of cert-manager yet. Changes will be reflected on a preview deployment for the release-next branch which is linked to from the main site.

Where's the documentation content?

First, docs go under content/; you shouldn't normally need to change files outside of content/ when making any documentation change.

There are several folders in content/ and which one you need depends on what you're changing:

• Something which applies to the current version of cert-manager?
  Add it to docs/ and possibly to the specific version of cert-manager that's latest (e.g. v1.8-docs/)
• Something which only applies to the next major version of cert-manager?
  Add it to docs/ but branch from the release-next branch and merge the PR into that branch. See above.
• Something which isn't "versioned", e.g. a page under "contributing", release notes or our supported-releases page?
  Add it to docs/, which is the only place such pages should appear
• Something which applies only to versions of cert-manager which have already been released?
  Change specific version docs (e.g. v1.8-docs/)

If you're not sure, ask! Reach out to us on slack and we'll point you in the right direction!

Task: Linking to other documentation pages

When working on documentation, all links to other documentation pages should be relative to the document you're working on and should point at a named markdown file.

For example, take this snapshot of the "Certificate Concepts" page.

There's an external link to an RFC which is fully specified as expected:

see [RFC 5246 section 7.4.2](https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.2)

But towards the end of the page we link to the "Certificate Usage" page:

[here](../usage/certificate.md).

If we're browsing the repository on the GitHub website (i.e. on this page), that relative link will work. In addition, the next.js framework will ensure that the link is correct by stripping the .md, so the final rendered link will be to https://cert-manager.io/docs/usage/certificate as we expect.

✨ When linking to an "Introduction" page, link to the README.md file directly. The framework will remove the whole filename, so e.g. [example link](../usage/README.md) will link to https://cert-manager.io/docs/usage/.

Task: Adding new pages

Documentation files aren't automatically picked up or added to the navigation on the site when created.

If you want a file to appear, you need to add it to the manifest.json file for the given version of the site you're working on.

For example, the manifest for the docs section contains the expected path for every file.

Task: Changing OpenGraph / social sharing tags

These tags are defined in Next.js code and config.

For docs pages, OpenGraph titles and descriptions are based on the titles and descriptions in the docs themselves, which is configured in the frontmatter for each docs page. The magic happens in in pages/[...docs].jsx.

For pages except docs and for some other tags, look at changing next-seo.config.js.

Task: Adding a Comment in Documentation

Sometimes you'll want to add a comment which is only for documentation maintainers.

Use {/* my comment */} rather than the HTML-style comments you'd normally use for Markdown files. Other comment types will cause errors.

Task: Merging master into release-next

In rare occasions, when writing documentation for an unreleased feature, you may notice that some recent changes in master aren't present in release-next. If that is a problem, you will want to update release-next branch with the latest changes from master. To update release-next with the changes made to master, follow these steps:

1. Create a PR to merge master into release-next using this magic link.

2. If you see the label dco-signoff: no, add a comment on the PR with:

    /override dco
   

   It is necessary because some the merge commits have been written by the bot and do not have a DCO signoff.

Website Development Tooling

First install nodejs (and package manager called npm). Then install all the tools and packages required to build the website as follows:

npm ci

This command is similar to npm install but it ensures that you will have a clean install of all the dependencies.

Development Server

The best development environment uses the Netlify CLI to serve the site locally. The Netlify CLI server closely matches the environment in which the website is deployed, and will enable local debugging of redirects and environment variables.

To run this server, install the Netlify CLI as follows:

npm install -g netlify-cli

Then run the server:

./scripts/server

Note that the server will also be accessible locally at port 3000, but that on this port there'll be no support for debugging redirects or environment variables. Use port 8888.

Initial builds of a page on the development server can be quite slow - a few seconds - but after the initial build changes should be picked up quickly and the development server should be snappy to use.

Running Verification Scripts

After you have made changes to the website, you should run the verify script to ensure things like spelling are valid. To run all verification checks:

./scripts/verify

This will automatically run a number of checks against your local environment, including:

• Lint checks on the nextjs code using next lint.
• Link checks on all pages using markdown-link-check.
• Spelling in all pages using mdspell.
• Formatting of the markdown in all pages using remark.

ℹ️ All these checks are also run automatically for pull requests. The results will be reported in the checks summary at the bottom of your GitHub PR. Read the cert-manager-website-presubmits.yaml prow configuration file and the check.yaml workflow file for more details.

Building for a Release

On release, all output is placed into the out/ directory. The full release process can be run through one script:

./scripts/build-release

API / CLI Documentation Generation

To update the API documentation and CLI documentation, run:

./scripts/gendocs/generate

This should be done before every cert-manager release (if the API or CLI flags have changed) and any time the API or CLI of the satellite projects changes, and the changes should be committed.

Since there are many old versions of cert-manager, none of which change regularly (or at all), the website build process does not re-generate documentation for older versions, on the assumption that doing so would be a waste of effort.

The solution for achieving this is simple; the generation scripts for older cert-manager versions are commented out. To rebuild, uncomment them and then re-comment after.

For versions of cert-manager older than v1.8, API doc generation used the old cert-manager import path and for this reason there's a different script - scripts/gendocs/generate-old-import-path-docs. If you want to rebuild reference docs for versions older than 1.8, you'll also need to uncomment generate-old-import-path-docs in scripts/gendocs/generate.

Signing Keys

Public keys used for verifying signatures are served on the website statically, and are located in public/public-keys directory.

See the docs on signing keys for more information about how and why these keys are generated and provided here.

website's Issues

Write release notes for v0.14

Document ACME account mismatch

We should add how to troubleshoot the error ACME server URL host and ACME private key registration host differ to the documentation.
Probably under https://cert-manager.io/docs/faq/acme/

Document kubectl cert-manager

We should document kubectl cert-manager, especially installation for the v0.15 installation.

[HTTP Validation] Adding example for GCLB

When you are going through the HTTP Validation tutorial on Google Cloud, you will be stuck on certificate status OrderCreated.

Although there is a note on the website:

If the ingress field is specified,
....
....
This field is useful for the GCLB ingress controller, as well as a number of others, that assign a single public IP address for each ingress resource
.... 

It took me a long while to understand GCLB = Google Cloud Load Balancer.

Might I suggest adding an example as below.

Note: The example below creates certificates for multiple domains, I think that's a useful additition in the example to consider the creation of http01 certificates for multiple domains.

---

For using cert-manger on Google cloud, create an ingress, example:

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: example-http-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: your-load-balancer-global-ip-name
spec:
  rules:
  - host: dashboard.example.com
    http: &https_rules
      paths:
      - path: /*
        backend:
          serviceName: openwisp-nginx
          servicePort: 80
  - host: controller.example.com
    http: *https_rules
  tls:
  - hosts:
    - dashboard.example.com
    - controller.example.com
    secretName: example-tls-secret

After you create the ingress, it will show an error that the example-tls-secret doesn't exist, that's an expected error and you can continue to create the Certificate and ClusterIssuer as below:

---
apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  namespace: default
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
      - http01:
          ingress:
            name: example-http-ingress
        selector: {}
---
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  namespace: default
  name: example-tls-crt
spec:
  secretName: example-tls-secret
  renewBefore: 12h
  dnsNames:
  - dashboard.example.com
  - controller.example.com
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer

You may have to wait for some minutes for the certificates to be created and propagated in the Google Cloud Infrasture properly.

---

Please let me know if this would be seen as a useful addition and I'll be happy to add it. 😄

Document keystores

We should document keystores in more detail for the v0.15 release

Cert-manager - Failed to decode returned certificate

Document how to use renewBefore to force a renewal

In order to mitigate the mass revocation that Let's Encrypt are performing today, we should urgently put up a guide/snippet on how to force renewals without causing downtime for users services.

/milestone v0.14
/priority critical-urgent

Document Certificate Subject Changes

In cert-manager 0.13 we have introduced a larger set of Subject attributes that can be specified on the Certificate resource.

We should make sure that all these options are documented in the Certificate Usage section.

FAQ: How does cert-manager handle ingresses with valid TLS secrets?

I'm trying to figure out if, when creating an ingress with a reference to a TLS secret that is populated with a valid certificate (hostname matches and date is within the valid from/until range), no attempts are being made to obtain a new certificate.

I am in the process of migrating from one Kubernetes cluster to another. The current cluster is using Traefik 1.7, using Traefik's own ACME resolver. I've written a script that parses the acme.json and generates TLS secrets for usage in my new cluster. All certificates used are Let's Encrypt issued. I'll be using cert-manager for renewing these in my new cluster. Since I'll be spinning up my services on the new cluster before actually changing the DNS, I'm hoping that adding the appropriate TLS secrets for the ingresses will prevent cert-manager from attempting to request Let's Encrypt certificates (given the certificates aren't near their expiration date of course). I haven't been able to validate this from the documentation. So maybe I've missed it, or maybe it's not yet there and it might be worth adding it!

Side note: great work on this piece of software! It's really easy to use and I am particularly happy that you've decided to implement ACME, not hardwire it to Let's Encrypt, since we're using an in-house ACME service of our own 👍

Restructure Helm installation

We should restructure the Helm installation documentation to note that helm 3 exists but still keep the Tiller related notes somewhere in there

Order of versions of cert-manager in menu

Could we change the order of this versions menu to be correct? Latest version is now below the before-last version.

Doc clarification

https://github.com/cert-manager/website/blob/master/content/en/docs/usage/certificate.md

cert-manager will not attempt to request a new certificate if the current certificate does not match the current key usages set.

Is this correct?

Release Notes

Missing 0.12 release notes.
Also, the list of "Release Notes" in the bottom half of the page is a little bit odd.

Improve webhook debugging info

As per #138 (comment)

We should refine our docs around webhook troubleshooting - we currently have a FAQ page that links to this document: https://github.com/cert-manager/website/blob/9568ec9f8fd67f416297ff4acb3ec4942e7fe5c7/content/en/docs/faq/webhook.md

Neither of these two pages provide that much debugging information. If anything, the concepts/webhook.md page provides the most in-depth info about what's going on.

Perhaps we should merge the FAQ page into this one, and extend it out to include information on how to debug issues with the webhook and/or explaining how the TLS assets are 'bootstrapped'? We're going to run into a lot more users with issues here over the coming weeks and having a single place to accumulate and communicate and advice would be great.

Setup redirects from old readthedocs site

DCO instructions link to non-existent CONTRIBUTING.md

The bot refers to https://github.com/cert-manager/website/blob/master/CONTRIBUTING.md, but this file does not exist.

Document JKS and p12 support flags

Kubernetes Installing with regular manifests section is missing challenge resources

In the documentation on https://cert-manager.io/docs/installation/kubernetes/#installing-with-regular-manifests is stated:

Installing with regular manifests

All resources (the CustomResourceDefinitions, cert-manager, namespace, and the webhook component) are included in a single YAML manifest file:

However, the yaml file appears to be missing the CRD's related to challenges, causing the cert-manager to log numerous messages like:

E0410 08:47:15.780099 1 reflector.go:153] external/io_k8s_client_go/tools/cache/reflector.go:105: Failed to list *v1alpha2.Challenge: the server could not find the requested resource (get challenges.acme.cert-manager.io)

This is noticed when trying to issue a letsencrypt-staging certificate.
If I rebuild the environment and apply the listed crds file (https://github.com/jetstack/cert-manager/releases/download/v0.14.1/cert-manager.crds.yaml) in the Helm section beforehand, everything works perfectly.

Can either the documentation on regular manifests installtion or the yaml file used in that section be updated so it works after following the listed steps?

Add Google Analytics

DNS01: Document Cloudflare API token usage

Our Cloudflare DNS01 guide is lacking any detail, and only contains a YAML snippet currently: https://github.com/cert-manager/website/blob/master/content/en/docs/configuration/acme/dns01/cloudflare.md

We should update this document to be a bit clearer, as well as documenting the newly introduce token based authentication (including what permissions the token requires in order to be usable).

There's more information on what permissions are required here: cert-manager/cert-manager#2170 (comment)

/good-first-issue
/help
/area acme/dns01

Uninstall link is broken

In https://cert-manager.io/docs/release-notes/release-notes-0.11/, there's a link to uninstall cert-manager, but it's broken.

broken helm links | Helm v3 no tiller

https://github.com/helm/helm/blob/master/docs/rbac.md

https://github.com/kubernetes/helm/blob/master/docs/install.md

I am trying to install this in AKS, by default helm 3 is installed and there is no tiller these instructions make reference to Tiller trying to understand what is still required.

Upgrading from v0.13 to v0.14

There is a typo in the documentation in the apiversion v1apha2

Note: If you’re using the cert-manager-legacy.yaml version you will not have API version conversion and thus only support cert-manager.io/v1apha2 API resources.

Add search functionality to the website

To make it easy to discover information across the website, we should add search functionality that covers at least the documentation.

Hugo is a static site generator, so this normally involves utilising some additional tooling. kubernetes.io uses "Google Custom Search", Algolia has also been recommended as a powerful alternative.

/help

`cert-manager` URL shown in the document is incorect

In the page Kubectl plugin, section Installation, there're commands to install kubectl-cert-manager.tar.gz using the released file from Github. However, the URL for the file using in the page is incorrectly spell cert-manager-liux instead of cert_manager-linux. So, when a user tries to use curl command from the page, the file content will be "Not Found" instead of the actual program.

I've already forked this repo and fix the issue. Please see the PR.

Thanks

Route53: document use of "region" field

The Route53 docs and API reference list a region field for the route53 solver, with the latter saying "Always set the region when using AccessKeyID and SecretAccessKey".

It's not clear what the value of this should correspond to, since IAM users and access keys are not associated with a region?

ACME - Replacing existing account in Kubernetes

It's not clear in the documentation how to change the account for Let's Encrypt, once it has been assigned.

The scenario is, that given cert-manager has been installed in several Kubernetes clusters, different secret keys get generated automatically for each cert-manager installation. These keys are used to register a new account in Let's Encrypt. The account (and account id) can be verified by inspecting Let's Encrypt ClusterIssuer:

#Some lines deleted for clarity

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    email: [email protected]
    privateKeySecretRef:
      key: tls.key
      name: letsencrypt-prod
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - http01:
        ingress:
          class: traefik
status:
  acme:
    lastRegisteredEmail: [email protected]
    uri: https://acme-v02.api.letsencrypt.org/acme/acct/123456790
  conditions:
  - lastTransitionTime: "2020-01-08T10:53:19Z"
    message: The ACME account was registered with the ACME server
    reason: ACMEAccountRegistered
    status: "True"
    type: Ready

Under status we can check the acccount id 123456790:

status:
  acme:
    lastRegisteredEmail: [email protected]
    uri: https://acme-v02.api.letsencrypt.org/acme/acct/123456790

Now, my assumption (based on my research) is that just replacing the secret specified in privateKeySecretRef, for the same one across the clusters, should be sufficient to have a single ACME account. However after doing that and trying to force certificate renewal, the account id in status remain unchanged.

Is there something else that should be done? Or should I just ignore this?
Documentation says nothing about this scenario.

AzureDNS DNS01 - The Service principal does not have authorization to perform action 'Microsoft.Network/dnsZones/TXT/write'

I've setup cert-manager and the SP as described here.

I've deployed cert-manager, however the logs are full of 403 errors, stating that the service principal does not have authorization to perform action 'Microsoft.Network/dnsZones/TXT/write'.

I've checked the DNS Zone Contributor role's permissions here and it does not appear to permit writing.

I believe the documentation is incomplete.

Kubernetes

It appears that there needs to be a slight modification in the helm install command on https://cert-manager.io/docs/installation/kubernetes/

Currently it reads:
$ helm install
--name cert-manager
--namespace cert-manager
--version v0.13.0
jetstack/cert-manager

Turns out that Helm doesn't want the --name flag as this returns
Error: unknown flag: --name

This does work:
$ helm install
cert-manager
--namespace cert-manager
--version v0.13.0
jetstack/cert-manager

SelfSignedIssuer configuration - API reference docs

In the example Deployment, the description says this:

Since the SelfSigned Issuer requires no dependency on any other resource to be configured, it is the simplest to configure. All that is required is for the SelfSigned stanza to be present in the issuers spec.

The YAML used is:

apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
  name: selfsigning-issuer
  namespace: sandbox
spec:
  selfSigned: {}

Therefore, is it safe to assume that, spec.selfSigned can be set to {}? It is not very clear as described here.

Securing NGINX-ingress: Silent failure after Step 7

The instructions are great, but they only consider the happy path, so for example, when I get to:
https://cert-manager.io/docs/tutorials/acme/ingress/#step-7-deploy-a-tls-ingress-resource and get no response to:
kubectl get certificate
I don't know where to look for the problem. Since everything up to that point has gone smoothly, I have to assume that I did something wrong in the previous step.... but that's not the case.

---

1. The docs are much improved, because the steps are very clearly described, along with the expected output, thank you.

2. you should have stayed on readthedocs, Sphinx is much better for authoring complex docs than static site generators like Hugo because is easier to embed cross references to other parts of the doc.

CA Injector - missing documentation for inject-ca-from?

According to Google, this page used to have documentation for cert-manager.io/inject-ca-from but now it just says:

This component is configured using the cert-manager.io/inject-apiserver-ca: "true" and cert-manager.io/inject-apiserver-ca: "true" annotations on the ValidatingWebhookConfiguration and MutatingWebhookConfiguration resources.

Note that it documents inject-apiserver-ca twice. Is the second reference supposed to be to inject-ca-from?

Kubernetes - Air-gapped installation

Is there any documentation describing how to install cert-manager in an air-gapped environment? ie. With no direct connection to internet.

From what I can make out the Kubernetes installation seems to require 3 containers (quay.io/jetstack/cert-manager-{controller,webhook,cainjector}), but is that all? Are there any other pre-requisites or dependencies that need to be downloaded?

Documenting repo management process

Since we have updated the way we handle branching in this repository, we should add a page to the docs on how everything works in this repository.

Roughly:

• All typos/docs changes that are relevant to the 'current' and future releases are made against master
• Changes for the next release are always made against release-next
• We periodically merge master into release-next
• When releasing version v0.X, we:
  • create branch release-0.(X-1) by branching from master
  • merge master into release-next one final time
  • update config on release-next to include the release-0.(X-1) branch (and any other changes required)
  • merge release-next into master

From there, the process repeats.

This process means that:

• master is always the currently published version of the docs
• release-next is always the docs for the next version of the docs
• release-0.X contains 'old' documentation versions and merges to these branches is ~never done (unless there's some exceptional circumstances that require it)

ACME

The docs regarding where a bit misleading concerning the nginxclass / nginxname explanations. But I managed to figure it out at the end.

Certificate Resources: keyAlgorithm case in example is wrong

Should be rsa not RSA - latter fails validation: spec.keyAlgorithm in body should be one of [rsa ecdsa].

Upgrading - page ordering is not great

https://cert-manager.io/docs/installation/upgrading/

I would expect the v0.11 to v0.12 item to be above the v0.10 to v0.11 entry.

Google CloudDNS

On https://cert-manager.io/docs/configuration/acme/dns01/google/ it says:

Note: If you have already added the Secret but get an error: ...due to error processing: error getting clouddns service account: secret "XXX" not found, the Secret may be in the wrong namespace. If you’re configuring a ClusterIssuer, move the Secret to the Cluster Resource Namespace which is cert-manager by default. If you’re configuring an Issuer, the Secret should be stored in the same namespace as the Issuer resource.

It seems to me that the secrets always need to be in the kube-system namespace (which honestly seems like a very strange choice of namespace.) This is when I am attempting to create a ClusterIssuer in the cert-manager namespace. I'm not sure if there's a way to configure the Cluster Resource Namespace?

Cloudflare permissions using API tokens

Following up to cert-manager/cert-manager#2878, the API token permissions listed at https://cert-manager.io/docs/configuration/acme/dns01/cloudflare/ seems to be wrong. Can you tell me what permissions are needed for the usage of API tokens?

Thanks!

v0.14: K8S Verifying Install, Doc says use ClusterIssuer, Example uses Issuer

https://cert-manager.io/docs/installation/kubernetes/#verifying-the-installation

The procedure to test a self-signed certificate issuance directs the user to "Create a ClusterIssuer to test the webhook works okay", however, the example uses an Issuer (kind).

I'll follow up with a PR that assumes the example code is the source of truth.

Filling out content on homepage

Move tools from /hack into /tools

We should remove the larger tooling out of /hack into a new top level directory /tools.
These include:

• api-migration
• bin
• build
• ci
• filter-crd

This will leave the /hack directory to only contain shell scripts and their text file dependencies.

Document v0.13 to v0.14 upgrade

We should document the v0.13 to v0.14 upgrade.

Things to be noted

• Introduction of the legacy manifests (which to use now)
• Webhook now being required
• Deployment selector issue

Add 'unreleased version' & 'old version' warning banner to non-latest versions of docs

To make it clear to users when they are looking at unreleased or old versions of the docs, we should include a banner at the very top of the page/under the header bar indicating to the user that the version they are looking at is not 'current'.

I'm not sure what the best-practice way to do this is, we could either hook into the versioning system/plugin configuration or otherwise string match on the URL that the user is viewing.

Upgrading from v0.10 to v0.11 - missing cainjector annotation

The annotation is missing from the table:
old: certmanager.k8s.io/inject-ca-from
new: cert-manager.io/inject-apiserver-ca

I'll try to get a few moments to submit a PR tomorrow!

Installation/Kubernetes: Helm chart v0.12.0-beta.1 does not exist jet

https://cert-manager.netlify.com/docs/installation/kubernetes/#steps

$ helm install
--name cert-manager
--namespace cert-manager
--version v0.12.0-beta.1
jetstack/cert-manager

Fails because Helm chart v0.12.0-beta.1 does not exist jet

PS > helm install cert-manager --namespace cert-manager --version v0.12.0-beta1 jetstack/cert-manager
Error: failed to download "jetstack/cert-manager" (hint: running `helm repo update` may help)

PS> helm search repo -l jetstack/cert-manager
NAME                    CHART VERSION   APP VERSION     DESCRIPTION
jetstack/cert-manager   v0.11.0         v0.11.0         A Helm chart for cert-manager
jetstack/cert-manager   v0.10.1         v0.10.1         A Helm chart for cert-manager
jetstack/cert-manager   v0.10.0         v0.10.0         A Helm chart for cert-manager
jetstack/cert-manager   v0.9.1          v0.9.1          A Helm chart for cert-manager
jetstack/cert-manager   v0.9.0          v0.9.0          A Helm chart for cert-manager
jetstack/cert-manager   v0.8.1          v0.8.1          A Helm chart for cert-manager
jetstack/cert-manager   v0.8.0          v0.8.0          A Helm chart for cert-manager
jetstack/cert-manager   v0.7.2          v0.7.2          A Helm chart for cert-manager
jetstack/cert-manager   v0.7.1          v0.7.1          A Helm chart for cert-manager
jetstack/cert-manager   v0.7.0          v0.7.0          A Helm chart for cert-manager
jetstack/cert-manager   v0.6.0          v0.6.0          A Helm chart for cert-manager
jetstack/cert-manager   v0.5.2          v0.5.2          A Helm chart for cert-manager

Add index job on updating the website

Currently our search index updates every 12 hours in a Prowl job.
We should be looking into leveraging Netifly webhooks in order to run a new index job whenever our website is updated. This will be especially useful when releasing a new version where it needs to create a whole new index for the versions.

Add documentation for CRD conversion webhook ca injection

CA injection is only documented for Validating and MutatingWebhookConfiguration but it works also for CRD conversion webhooks: cert-manager/cert-manager#1505

Index release-next

We need to submit a fix to https://github.com/algolia/docsearch-configs/blob/master/configs/cert-manager.json
in order to also index the release-next branch

Document release process

Quick notes/thoughts:

• Merge 'master' of cert-manager/website into 'release-next'
• PR release notes to documentation site
• Update version numbers on documentation site
• Ensure CI config in jetstack/testing is up to date
• Fast forward release branch
• Stage the new version with cmrel
• Publish the new version with cmrel
• Update jetstack/cert-manager-olm: cert-manager/cert-manager-olm#7
• Trigger build in Red Hat portal
• Merge 'release-next' into 'master'
• PR to docsearch with the new version/index

/kind documentation