Release Notes
The v0.10
release comes quick on the heels of v0.9
. It continues the work on
the new 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
the 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 v0.11
!
We’ve also simplified the way we bootstrap TLS certificates for the ‘webhook’
component. Now, instead of creating an Issuer
and 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
Alpha
Hans Kristian Flaatten
James Munnelly
Jonas-Taha El Sesiy
JoshVanL
Marcello Romani
Moritz Johner
Nicolas Kowenski
Olaf Klischat
Vasilis Remmas
stuart.warren
zeeZ
Notable Items
All Issuer types now supported with CertificateRequests
The CertificateRequest
design proposal, first implemented in v0.9
, changes the
way we request certificates from Issuers
in order to allow out-of-tree Issuer
types.
This required us to refactor and adapt our existing in-tree Issuer
types to
follow a similar pattern.
The 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 certmanager.k8s.io
,
as well as enabling the CertificateRequestControllers
feature gate on the
controller
component of cert-manager.
Simplified webhook TLS bootstrapping
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.
KeyUsages
on Certificate resources
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!
Preparation for v1alpha2
and beyond
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. v1beta1
and v1
) will be
automatically converted using a Kubernetes conversion webhook (available in
beta from Kubernetes 1.15 onward).
Action Required
No special actions are required as part of this release.
Changelog
General
- Add
DisableDeprecatedACMECertificates
feature gate to disable the old deprecated ACME configuration format (#1923,@munnerz
) - chart: fix formatting of values table in
README.md
(#1936,@Starefossen
) - Add internal API version and implement machinery for defaulting & conversion (#2002,
@munnerz
) - Fix concurrent map write panic in certificates controller (#1980,
@munnerz
) cainjector
: allow injecting CAs directly from Secret resources (#1990,@munnerz
)- Mark
spec
andstatus
as non-required fields in CRDs (#1957,@munnerz
) - Add ability to specify key usages and extended key usages in certificates (#1996,
@stuart-warren
)
ACME Issuer
- Add option to assume role in Route53 DNS01 provider (#1917,
@moolen
) - Fix documentation for AzureDNS service principal creation (#1960,
@elsesiy
)
Webhook
CertificateRequest
- Add ACME
CertificateRequest
controller implementation (#1943,@JoshVanL
) - Add Vault
CertificateRequest
controller implementation (#1934,@JoshVanL
) - Add
SelfSigned
CertificateRequest
controller implementation (#1906,@JoshVanL
) - Add Venafi
CertificateRequest
controller implementation (#1968,@JoshVanL
) - Don’t validate
issuerRef.kind
field ifissuerRef.group
is set in order to support out-of-tree Issuer types (#1949,@munnerz
) - Adds
CertificateRequest
FailureTime
. The Certificate controller will re-try failedCertificateRequests
at least one hour after this failed time. (#1979,@JoshVanL
)
Monitoring
- Added variable to specify custom namespace where to deploy
ServiceMonitor
resource (#1970,@mogaal
) - helm: fix labels and add Service for Prometheus
ServiceMonitor
(#1942,@Starefossen
)