v0.12.0 release is finally ready! After a KubeCon-induced delay, this
version focuses on usability, user experience, bug-fixes and documentation.
A big notable feature in this release is the new
website - this has been a long time coming, but we hope that the information
on this site should more clearly walk new and experienced users alike through
the tool, and with it the rewrite into Markdown (with Hugo)
should make external contributions easier!
The rest of the notable features below are all focused on usability, and as
such, the upgrade process from
v0.11 should be nice and easy :holiday:.
We’ll be doing an in-depth walk-through of this release and what’s planned for for the next release during the next community call on Wednesday 4th December! For more details on joining and getting involved, see the community section.
This release has seen code contributions from a number of people in the community:
Benjamin P. Jung
Bouke van der Bijl
Joshua Van Leeuwen
As always, a big thank you to those opening issues, replying to issues and helping out in the Slack channel. As well as working in other projects to help users secure services running on Kubernetes.
We have launched a new website to better showcase cert-manager, which can be
With this new site, we have also significantly restructured and rewritten the documentation for the site in order to flow better, and hopefully inform users more on the inner-workings of cert-manager whilst still making on-boarding to the project easy.
Whilst this is the first launch of the new website, there is still lots to do! If you have any feedback, ideas or expertise to improve the site, please open an issue or make a contribution over in the new cert-manager/website repository.
If you run a non-homogeneous or alt-architecture cluster (i.e.
then you may have run into issues when deploying cert-manager.
For almost a year now, we have published Docker images built for these
architectures, but due to limitations in
quay.io, using these images has
required changing deployment manifests and passing additional flags to
different cert-manager components.
v0.12, we make use of
Docker Image Manifests v2.2,
which means that you will no longer have to make any changes to the
deployment manifests in order to deploy cert-manager into your cluster!
This is a big usability win for users of non-
amd64 systems, and a big +1
Making it easier to debug failing ACME challenges
During the ACME authorization flow, a number of issues can arise such as misconfigured DNS records or ingress controllers.
This release makes it simpler to identify these issues when they occur,
providing additional debugging information through the user of
kubectl describe challenge <name-of-failing-challenge>.
Whilst this is a small addition, it vastly improves the user experience for first time users who may have configuration issues with their DNS records or cert-manager installation, another win for usability!
Simplifying the webhook component
For those of you upgrading from older versions of cert-manager, you may already be aware of some of the deployment issues with the ‘webhook’ component in cert-manager.
In previous releases, this component relied on the creation of an
resource in order for the Kubernetes apiserver to utilize the webhook and
provide additional validation for our
APIService is a powerful resource, however, due to its nature, can cause
certain core operations (such as garbage collection) to not function if the
webhook becomes unavailable at any point, which can in turn cause cascading
failures in your Kubernetes cluster in the worst of cases.
v0.12, we have rewritten this component almost entirely, and we no longer
make use of the
APIService resource in order to expose it.
This should mean deploying the webhook is far easier, and far less likely to cause cluster-wide issues.
We have also extended the webhook to support ‘API conversions’ for our CRD
types. Whilst we don’t currently make use of this functionality, when we
v1beta1 we will make use of it, at which point the webhook
will be a required component in clusters running Kubernetes 1.15 or greater.
ACTION REQUIRED Users who have previously set the Kubernetes Auth Mount Path will need to update their manifests to include the entire mount path. The
/loginendpoint is added for you.
Changes the Vault Kubernetes Auth Path to require the entire mount path.
/loginis added to all mount paths when authenticating. The default auth path has now changed from
- Fixes issues with Pod Security Policies that prevented pods from running when Pod Security Policy is enabled in Kubernetes (#2234,
- Fix issue causing certificates not to be issued when running with
OwnerReferencesPermissionEnforcementadmission controller enabled (#2325,
- Fix bug causing SIGTERM and SIGINT signals to not be respected whilst the controller is performing leader election (#2236,
- Fix setting
ownerReferenceon Challenge resources created by Orders controller (#2324,
CloudDNSresolvers to be validated correctly without
serviceAccountSecretRefto allow ambient permissions to be used. (#2250,
- Add missing
- Perform API resource validation of the ‘status’ subresource on cert-manager resources (#2283,
- Fix outdated documentation for solver configuration in
Other Notable Changes
- Explicitly define
containerPortprotocol in helm chart (#2405,
- Allow permissive acceptance for matching Certificates with Secrets that are using legacy annotations to reduce non-required certificate reissue.
- Add API token authentication option to CloudFlare issuer (#2170,
- Bump Kubernetes client library dependencies to 1.16.3 (#2290,
- Build using go 1.13.4 (#2366,
certificaterequest.spec.csrfield as required in OpenAPI schema (#2368,
serverAuthextended key usage to Certificates by default (#2351,
- Surface more information about ACME authorization failures on Challenge resources (#2261,
- Add documentation for the webhook (#2252,
- Add support for API resource conversion to the webhook. NOTE: this feature is not currently utilized by cert-manager (#2001,
- Remove nested
cainjectorsub chart and include it in main chart (#2285,
- Change the default webhook listen address to 10250 for better compatibility with GKE private clusters (#2278,
- Bump Helm & Tiller version used during end-to-end tests to 2.15.1 (#2275,
status.authorizations.challenges.tokenfields on Order resources immutable (#2219,
- No longer use architecture specific
- enable cert-manager using
--kubeconfigto connect API Server with
- Publish multi-architecture docker manifest lists (#2230,
- Kubernetes APIServer dry-run is supported. (#2206,