Release Notes
The 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 cert-manager.io
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.
Contributors
This release has seen code contributions from a number of people in the community:
Adrian Mouat
Benjamin P. Jung
Bouke van der Bijl
Christian Groschupp
Christophe Courtaut
Eric Bailey
Harold Drost
Ingo Gottwald
James Munnelly
JayatiGoyal
Joshua Van Leeuwen
Krishna Durai
Luca Berneking
Matevz Mihalic
Max Goltzsche
Nick Parker
Nils Cant
Nolan Reisbeck
Pierre Dorbais
Sam Cogan
Thomas
chenjun.cj
ismail BASKIN
walter.goulet
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.
Notable changes
New website
We have launched a new website to better showcase cert-manager, which can be
found at cert-manager.io
.
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.
Multi-architecture images
If you run a non-homogeneous or alt-architecture cluster (i.e. arm
or arm64
)
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.
As of 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
for usability!
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 APIService
resource in order for the Kubernetes apiserver to utilize the webhook and
provide additional validation for our CustomResourceDefinition
types.
An 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.
In 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
release the 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.
Changelog
Action Required
- 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
/login
endpoint is added for you.
Changes the Vault Kubernetes Auth Path to require the entire mount path. /login
is added to all mount paths when authenticating.
The default auth path has now changed from kubernetes
to /v1/auth/kubernetes
(#2349, @JoshVanL
)
Bug Fixes
- Fixes issues with Pod Security Policies that prevented pods from running when Pod Security Policy is enabled in Kubernetes (#2234,
@sam-cogan
) - Fix issue causing certificates not to be issued when running with
OwnerReferencesPermissionEnforcement
admission controller enabled (#2325,@CoaxVex
) - Fix bug causing SIGTERM and SIGINT signals to not be respected whilst the controller is performing leader election (#2236,
@munnerz
) - Fix setting
ownerReference
on Challenge resources created by Orders controller (#2324,@CoaxVex
) - Allow
CloudDNS
resolvers to be validated correctly withoutserviceAccountSecretRef
to allow ambient permissions to be used. (#2250,@baelish
) - Add missing
apiVersion
toChart.yaml
(#2270,@yurrriq
) - Perform API resource validation of the ‘status’ subresource on cert-manager resources (#2283,
@munnerz
) - Fix outdated documentation for solver configuration in
Issuers
andClusterIssuers
(#2210,@nickbp
)
Other Notable Changes
- Explicitly define
containerPort
protocol in helm chart (#2405,@bouk
) - Allow permissive acceptance for matching Certificates with Secrets that are using legacy annotations to reduce non-required certificate reissue.
(#2400,
@JoshVanL
) - Add API token authentication option to CloudFlare issuer (#2170,
@matevzmihalic
) - Bump Kubernetes client library dependencies to 1.16.3 (#2290,
@munnerz
) - Build using go 1.13.4 (#2366,
@munnerz
) - Mark
certificaterequest.spec.csr
field as required in OpenAPI schema (#2368,@munnerz
) - Add
serverAuth
extended key usage to Certificates by default (#2351,@JoshVanL
) - Surface more information about ACME authorization failures on Challenge resources (#2261,
@munnerz
) - Add documentation for the webhook (#2252,
@cgroschupp
) - Add support for API resource conversion to the webhook. NOTE: this feature is not currently utilized by cert-manager (#2001,
@munnerz
) - Remove nested
cainjector
sub chart and include it in main chart (#2285,@munnerz
) - Change the default webhook listen address to 10250 for better compatibility with GKE private clusters (#2278,
@munnerz
) - Bump Helm & Tiller version used during end-to-end tests to 2.15.1 (#2275,
@munnerz
) - Make
spec.csr
,status.url
,status.finalizeURL
,status.certificate
,status.authorizations
,status.authorizations[].url
,status.authorizations[].identifier
,status.authorizations[].wildcard
,status.authorizations[].challenges
,status.authorizations[].challenges[].url
,status.authorizations[].challenges[].type
,status.authorizations[].challenges[].token
fields on Order resources immutable (#2219,@munnerz
) - No longer use architecture specific
acmesolver
images (#2242,@munnerz
) - enable cert-manager using
--kubeconfig
to connect API Server withkubeconfig
file (#2224,@answer1991
) - Publish multi-architecture docker manifest lists (#2230,
@munnerz
) - Make
order.status.authorizations[].wildcard
field a*bool
(#2225,@munnerz
) - Kubernetes APIServer dry-run is supported. (#2206,
@ismailbaskin
)