v0.14 release has a few focus areas:
- Improving the deployment/installation process
- Improving the release process
- Support for older Kubernetes and OpenShift versions
- Experimental 'bundle' output format for Certificates
As usual, please read the upgrade notes before upgrading.
The webhook component is now required. The webhook will be automatically enabled by the
v0.14 manifests, so no additional action is required.
If you have issues running the webhook in your environment, we'd like to hear from you! We are aware of issues relating to firewall rules from the Kubernetes API server to the webhook pod(s) - we would like to gather together a corpus of configuration snippets that can be used to ensure the webhook is successfully deployed in these environments too.
This change is required in order to support the upcoming changes to our API versions, as we introduce
v1 over the coming months!
After reports of various issues installing on older Kubernetes and OpenShift versions, we've taken some time to revise our installation manifests.
There are now two 'variants' to choose from, 'standard' and the 'legacy', with a simple way to know which to use:
|Environment||Variant to use|
Please be sure to read the upgrade guide for more information on how to upgrade from a previous release.
As part of the effort to mature our API, we are releasing the
v1alpha3 API version. This contains a number of small
changes, notably moving some fields to the
subject stanza on the Certificate resource to be more consistent with how
certain options are specified.
With this we have enabled the 'conversion webhook', which enables API clients to utilize both the
v1alpha3 APIs simultaneously, similar to other core resources in Kubernetes.
Thanks to this conversion webhook, this upgrade and future upgrades after it should be seamless. The ability to make
these kinds of changes to our API will enable the
v1beta1 API version to be released in a seamless manner in an
upcoming release too.
More information on the webhook can be found in the concepts section.
We've had a number of users who are using OpenShift 3.11 & Kubernetes 1.11 reach out requesting support with installation. In this release, we've expanded the range of Kubernetes versions we support to once again include 1.11, as well as adding support for OpenShift 3.11.
A big thanks to
@meyskens for putting this together!
One of our top feature requests has been for support for JKS and PKCS#12 bundle files as an output from Certificate resources.
In this release, we've added experimental support for both of these bundle formats. This can currently only be
configured globally with flags provided to the
cert-manager pod (
--experimental-issue-pkcs12). The password used for this bundle must also be configured using the flags
In the next release, we are aiming to provide native support for these bundle format types as part of the Certificate resource configuration. We have added these flags now in order to gather feedback on the way this feature works, and help guide how this feature should work in future.
Users of the Venafi issuer often need to set custom metadata on their certificate requests in order to better associate each request with different business areas, or in order to validate & authorize whether a request should be signed.
In this release, we've added support for setting custom metadata by adding the
CertificateRequest resources. If using the Venafi TPP integration, version 19.2 or
greater is required.
- Update Deployment selector to follow Helm chart best practices. This will require deleting the three cert-manager Deployment resources before upgrading. (#2654,
--experimental-issue-jksflag to enable JKS bundle generation in generated Secret resources. This flag will be replaced with native support for JKS bundles in future and is currently an experimental feature. If enabled, the
--experimental-jks-passwordflag must also be set to the password used to encrypt JKS bundles. (#2647,
--experimental-issue-pkcs12flag to enable PKCS12 bundle generation in generated Secret resources. This flag will be replaced with native support for PKCS12 bundles in future and is currently an experimental feature. If enabled, the
--experimental-pkcs12-keystore-passwordflag must also be set to the password used to encrypt PKCS12 bundles. (#2643,
venafi.cert-manager.io/custom-fieldsannotation for Venafi custom fields (#2573,
emailSANsfield to Certificate resource (#2597,
--tls-cipher-suitescommand line flag to the webhook binary with sensible defaults (#2562,
- Build OpenShift 3.11 compatible CRDs (#2609,
- Enable CRD conversion webhook and begin serving
- Improve startup time for webhook pod. (#2574,
00-crds.yamlfile with a manifest file published as part of the release (#2665,
Venafi/vcertdependency to support custom fields in Venafi TPP 19.2 (#2663,
OwnerReferenceof resources created by HTTP01 challenge solver, causing HTTP01 validations to fail on OpenShift 4 (#2546,
- Fix Venafi Cloud URL field being marked required (#2568,
- Fix bug in ingress-shim causing Certificate resources to be rapidly updated if multiple
spec.tls.hostsentries refer to the same Secret name but a different set of hosts (#2611,
- Fix bug that could cause certificates to be incorrectly issued with an invalid public key (#2539,
cainjector.enabled=Falseoverride being ignored by the Helm Chart (#2544,
- Include license header in manifests attached to GitHub releases (#2684,
- Make the webhook
RoleBindingthe leader election namespace instead of hard-coded
no-webhookmanifest variants with a "legacy" variant (#2648,
- Truncate message display if HTTP01 self check fails (#2613,
- Upgrade to Go 1.14 (#2656,
//build/release-tarstargets for generating release artifacts (#2556,
- Improve local testing and development environment setup code (#2534,
isOpenShiftfrom Helm chart (#2642,
webhook.enabledvariable in Helm chart as the webhook now is a required component (#2649,