The cert-manager maintainers at Jetstack are proud to announce the release of cert-manager 1.5. This release coincides with the recent release of Kubernetes v1.22, and supports every version down to and including Kubernetes 1.16, which includes Openshift Container Platform 4.3 - 4.8.
We’ve included two features in cert-manager 1.5 that we are currently working on. These are marked alpha as the implementation could change in future, so have to be explicitly enabled by passing command-line flags to the cert-manager controller pod.
We have seen many requests from users to support different ways of routing HTTP traffic into their clusters for solving ACME HTTP-01 challenges. As the cloud-native ecosystem has so many different ingress implementations, we searched for a solution that would avoid having to add individual support for every kind of virtual service to the cert-manager API, and settled on the sig-network Gateway API.
The Gateway API project aims to provide a universal API for modelling service
networking in Kubernetes, and while it is still in its alpha stages is already
supporting the Gateway API
HTTPRoute, we hope that anyone using Ambassador,
Contour, Gloo, HAProxy, Istio, Kong or Traefik will be able to solve HTTP-01
challenges, with more implementations coming in future.
To go along with the
HTTPRoute support, we have also added a gateway-shim controller that will allow
users to annotate their
Gateways to get a cert-manager
Certificate automatically created, similar
to the current ingress-shim functionality.
To start using the Gateway API with cert-manager, please take a look at the Securing Gateway Resources page on the cert-manager website.
CertificateSigningRequest is a built-in Kubernetes resource that was originally aimed at requesting X.509 client certificates and serving certificates for Kubernetes components such as kubelet.
We have seen a rising interest in using the CertificateSigningRequest (CSR) resource as a way to provision workload certificates in service meshes such as Istio and its Istio Custom CA Integration using Kubernetes CSR. For that purpose, the CSR resource needs to be integrated with existing signers such as HashiCorp Vault or Venafi TPP.
Back in cert-manager 1.4, the CA Issuer became the first built-in cert-manager issuer to
CertificateSigningRequest resources. In 1.5, we extended the support to all existing Issuers.
If you are interested in trying this out, please take a look at the Kubernetes CertificateSigningRequest documentation on the cert-manager website.
Improvements have also been made to the experience of installing and using cert-manager.
cert-manager comes with a kubectl plugin,
kubectl cert-manager, that comes in handy for checking the status of your cert-manager Certificate resources.
In 1.5, the plugin was taught how to install cert-manager. To try it out, run the command:
kubectl cert-manager x install
The plugin is now capable of determining when your cert-manager deployment is ready to be used:
kubectl cert-manager check api
The plugin also learned to guess the version of cert-manager running on your cluster, similarly as to
kubectl cert-manager version
To install the plugin, check out the Kubectl plugin page on the cert-manager website.
While installing cert-manager using Helm, you might have noticed that the
--wait flag does not wait until cert-manager is fully functional.
With 1.5, the
--wait flag now works as you would expect. The Helm chart now comes with a small startup job that waits until the cert-manager API becomes ready.
Labels and Annotations on Generated Secret and CertificateRequest Resources
cert-manager now allows you to add custom annotations and labels to the Secret
containing the TLS key pair using the new Certificate field
This is useful when using third-party solutions such as
kubed to copy Secret resources to multiple
secretTemplate is synced to the Secret when the Certificate is
created or renewed.
Here is an example of Certificate using the
apiVersion: cert-manager.io/v1 kind: Certificate spec: secretTemplate: annotations: my-secret-annotation: "foo" labels: my-secret-label: bar
Note that labels and annotations can only be added or replaced, but not removed. Removing any labels or annotations from the template or removing the template itself will have no effect.
Along with the ability to set your own annotations and labels on Secret resources created by cert-manager, you can also tell cert-manager which annotations should be copied from Certificate resources to the generated CertificateRequest resources. By default, cert-manager will skip copying the annotations with the following prefixes:
If you wish to keep the old behavior and allow all annotations to be copied, you
can pass the flag
--copied-annotations=* to the cert-manager controller.
The recent Kubernetes 1.22 release has removed a number of deprecated APIs. You can read the official blog post Kubernetes API and Feature Removals In 1.22 to learn more about it. If you intend to upgrade to Kubernetes 1.22, you must upgrade to cert-manager 1.5.
To keep compatibility with older Kubernetes versions (down to 1.16), cert-manager 1.5 is now compatible with both Ingress
v1beta1. cert-manager will default to using
v1 Ingress, and fall back to
v1 is not available.
Additionally, the cert-manager API versions
v1beta1 are now deprecated, and will be removed in cert-manager 1.7. Please change all your YAML manifests that use a deprecated API version to use
cert-manager.io/v1 instead, and re-apply them.
Thanks again to all open-source contributors with commits in this release. Please see the release notes for cert-manager 1.5 for a complete list.
— the cert-manager maintainers.