v0.10 release comes quick on the heels of
v0.9. It continues the work on
CertificateRequest resource type, moving us towards a world where
out-of-tree Issuer types are first class citizens.
As a project, we're pushing towards a 'stable' API release and eventually, a
v1.0 release. This release, and the releases to follow over the coming months,
lay the foundation for these milestones. Keep an eye on the releases page over
the coming months for some exciting new developments!
You can get started using the new
CertificateRequest controllers by enabling
CertificateRequestControllers feature gate - all Issuer types are now
supported, and your feedback is extremely valuable before we switch the new
implementation to be the default in
We've also simplified the way we bootstrap TLS certificates for the 'webhook'
component. Now, instead of creating an
Certificate resource for the
webhook (requiring you to disable validation on the cert-manager namespace),
we've implemented a dedicated
webhookbootstrap controller which will manage
TLS assets for the webhook.
This release includes changes from:
Alejandro Garrido Mota
Hans Kristian Flaatten
Jonas-Taha El Sesiy
CertificateRequest design proposal, first implemented in
v0.9, changes the
way we request certificates from
Issuers in order to allow out-of-tree Issuer
This required us to refactor and adapt our existing in-tree
Issuer types to
follow a similar pattern.
v0.10 release finishes this refactoring so that all
Issuer types now
support the new format.
As the feature is currently still in an 'alpha' state, you must set the
issuerRef.group field on your Certificate resources to
as well as enabling the
CertificateRequestControllers feature gate on the
controller component of cert-manager.
In past releases, we've managed TLS for the webhook component by creating an internal self signed and CA issuer that is used to mint serving certificates for the apiserver to authenticate the webhook's identity.
This introduced a number of complexities in our installation process and has caused trouble for users in the past.
In order to simplify this process and to support running a CRD conversion
webhook in future (to provide seamless migration between API versions), we've
introduced a dedicated
webhookbootstrap controller that relies on flags and
Secret resources in order to configure TLS for the webhook.
This will mean easier installation as well as future-proofing for our upcoming plans in future releases.
In order to support a more diverse set of applications, including apps that
require client-auth certificates, a new field
keyUsages has been added which
accepts a list of usages that must be present on a Certificate.
These will be automatically added when certificates are issued, just like any other field on the Certificate.
Thanks to Stuart Warren from Ocado for this change!
Over the last few releases, we've been making a number of significant changes to our API types (i.e. moving ACME configuration from Certificate resources onto the Issuer resource). This has involved deprecating some old API fields.
In a future release, we'll be removing these deprecated fields altogether, requiring users to update their manifests to utilize the new way to specify configuration.
A number of steps have been taken in our own code base to support this change,
and in a future release, you'll be required to update all your manifests for
this new format. Future API revisions (e.g.
v1) will be
automatically converted using a Kubernetes conversion webhook (available in
beta from Kubernetes 1.15 onward).
No special actions are required as part of this release.
DisableDeprecatedACMECertificatesfeature gate to disable the old deprecated ACME configuration format (#1923,
- chart: fix formatting of values table in
- Add internal API version and implement machinery for defaulting & conversion (#2002,
- Fix concurrent map write panic in certificates controller (#1980,
cainjector: allow injecting CAs directly from Secret resources (#1990,
statusas non-required fields in CRDs (#1957,
- Add ability to specify key usages and extended key usages in certificates (#1996,
- Add option to assume role in Route53 DNS01 provider (#1917,
- Fix documentation for AzureDNS service principal creation (#1960,
- Add ACME
CertificateRequestcontroller implementation (#1943,
- Add Vault
CertificateRequestcontroller implementation (#1934,
CertificateRequestcontroller implementation (#1906,
- Add Venafi
CertificateRequestcontroller implementation (#1968,
- Don't validate
issuerRef.groupis set in order to support out-of-tree Issuer types (#1949,
FailureTime. The Certificate controller will re-try failed
CertificateRequestsat least one hour after this failed time. (#1979,