cert-manager

Bug fixes

• Fix Venafi Cloud URL field being marked required (#2583, @munnerz)
• Fix cainjector.enabled=False override being ignored by the Helm Chart (#2552, @gtaylor)
• Fix bug that could cause certificates to be incorrectly issued with an invalid public key (#2543, @munnerz)
• Fix GroupVersionKind set on OwnerReference of resources created by HTTP01 challenge solver, causing HTTP01 validations to fail on OpenShift 4.x (#2554, @munnerz)

The v0.13 contains a number of important bug-fixes and a few notable feature additions. It is a minor, incremental update over v0.12 and does not require any special upgrade steps.

ACME External Account Binding support

Users that wish to use cert-manager with ACME servers other than Let's Encrypt may have found themselves unable to register an account due to the lack of (EAB) 'External Account Binding' support. This allows an ACME server to validate that a user is somehow associated with some other entity, like an account in the CAs customer management system.

With EAB support, it's now possible to specify additional parameters (spec.acme.externalAccountBinding) on your ACME Issuer resource and utilize cert-manager with your preferred ACME provider.

Support for full set of x509 'subject' parameters

In this release, support for the full range of 'subject' parameters as per the x509 specification has been added. This means you can set fields like organizationalUnit, provinces, serialNumber, country, and all other standard x509 subject fields.

A big thanks to @mathianasj for this addition!

InvalidRequest status condition for CertificateRequest resources

For the growing ecosystem of developers creating their own 'external issuer types' for cert-manager, we have added support for a new 'status condition' type InvalidRequest - this can be used to signal from your signer/issuer to cert-manager that the parameters that the user has requested on the x509 CSR are 'invalid' and the CSR should not be retried.

This prevents users expending API quotas and making requests that will never succeed.

Bug Fixes

• Fix invalid service account name used in RBAC resources when manually specifying a service account name (#2509, @castlemilk)
• fixed a bug that in certain cases could cause HTTP01 ingress serviceName fields to be incorrectly set (#2460, @greywolve)
• Fix bug causing ever-increasing CPU usage in webhook component (#2467, @munnerz)
• Fix bug causing temporary certificates to overwrite previously issued certificates when adding a new dnsName to an existing Certificate resource (#2469, @munnerz)
• Fix certmanager_certificate_expiration_timestamp_seconds metric recording (#2416, @munnerz)
• Fixes ClusterIssuers not finding the secret when the secret is in a different namespace than the certificate request using the Venafi issuer type (#2520, @mathianasj)
• Fixes generation if invalid certificate name the the 52nd character in a domain name is a symbol. (#2516, @meyskens)

Other Notable Changes

• Adds InvalidRequest condition type to CertificateRequest, signaling to not retry the request. (#2508, @JoshVanL)
• Add volume and volume mounts field to cert-manager helm chart (#2504, @joshuastern)
• Add support for additional x509 'subject' fields (#2518, @mathianasj)
• Bump k8s.io/* dependencies to Kubernetes 1.17.0 (#2452, @munnerz)
• It is now possible to disable AppArmor when Pod Security Policies are used. (#2489, @czunker)
• Support for arbitrary securityContext parameters (#2455, @nefischer)
• Remove misleading 'error decoding x509 certificate' message (#2470, @munnerz)
• Remove IP address validation on dns01-recursive-nameservers to allow domain names (#2428, @haines)
• Optional webhook.securityContext and cainjector.securityContext chart parameters to specify pods security context. (#2449, @nefischer)
• webhook: register HTTP handlers for pprof debug endpoints (#2450, @munnerz)
• Adds support for chart configurable parameters deploymentAnnotations, webhook.deploymentAnnotations and cainjector.deploymentAnnotations (#2447, @nefischer)
• Adds ACME external account binding support (#2392, @JoshVanL)
• Fix false-y values in helm chart to mitigate kubernetes/kubernetes#66450 (#2383, @colek42)
• Explicitly define containerPort protocol in helm chart (#2405, @bouk)
• Switch to using upstream golang.org/x/crypto/acme ACME client library (#2422, @munnerz)

This is an alpha release of v0.13. This has been cut early on to provide sufficient time for feedback and gather data on ACME API usage since upgrading our ACME client library to use the upstream golang crypto library, as well as to gather feedback on the newly added 'external account binding' feature.

The v0.13 release is not currently 'feature complete', and additional features will be added ahead of the final release.

Features

• Switch to using upstream golang.org/x/crypto/acme ACME client library (#2422, @munnerz)
• Adds ACME external account binding support (#2392, @JoshVanL)

Bug Fixes

• Fix certmanager_certificate_expiration_timestamp_seconds metric recording (#2416, @munnerz)

Other Notable Changes

• Adds support for chart configurable parameters deploymentAnnotations, webhook.deploymentAnnotations and cainjector.deploymentAnnotations (#2447, @nefischer)
• Optional webhook.securityContext and cainjector.securityContext chart parameters to specify pods security context. (#2449, @nefischer)
• webhook: register http handlers for pprof debug endpoints (#2450, @munnerz)
• Remove IP address validation on dns01-recursive-nameservers to allow domain names (#2428, @haines)
• Explicitly define ContainerPort protocol in helm chart (#2405, @bouk)
• Fix falsey values in helm chart to mitigate kubernetes/issues/66450 (#2383, @colek42)

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 walkthrough 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
mis-configured 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 utilise 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 without serviceAccountSecretRef to allow ambient permissions to be used. (#2250, @baelish)
• Add missing apiVersion to Chart.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 and ClusterIssuers (#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 utilised by cert-manager (#2001, @munnerz)
• Remove nested cainjector subchart 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 with kubeconfig 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)

This is the only and final patch release of v0.11. It fixes an issue when upgrading from older versions whereby cert-manager will request a new certificate for all Certificate resources immediately if you do not update the certmanager.k8s.io/issuer-name and certmanager.k8s.io/issuer-kind annotations manually on all Secret resources before upgrading.

It also fixes an issue that will cause Challenge resources to become orphaned if their parent Order resource is deleted.

Notable Changes

• Ensure secrets using deprecated secret annotations do not cause unneeded re-issuance (#2404, @JoshVanL)
• Fix setting ownerReference on Challenge resources created by Orders controller (#2333, @CoaxVex)
• Add missing apiVersion to Chart.yaml (#2300, @yurrriq)
• Kubernetes APIServer dry-run is supported. (#2213, @ismailbaskin)
• Fix outdated documentation for solver configuration in Issuers and ClusterIssuers (#2212, @nickbp)

This is a pre-release version of v0.12. It is considered feature complete, and has been released in order to gather feedback on the upgrade experience.

Full release notes are still TBD.

As part of this release, we have also launched a new documentation website. This website is still under construction, however the majority of the content is now available there.

You can view the documentation for v0.12 by clicking this link!

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 without serviceAccountSecretRef to allow ambient permissions to be used. (#2250, @baelish)
• Add missing apiVersion to Chart.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 and ClusterIssuers (#2210, @nickbp)

Other Notable Changes

• 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 utilised by cert-manager (#2001, @munnerz)
• Remove nested cainjector subchart 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 with kubeconfig 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)

This is a pre-release version of v0.12. It is considered feature complete, and has been released in order to gather feedback on the upgrade experience.

Full release notes are still TBD.

As part of this release, we have also launched a new documentation website. This website is still under construction, however the majority of the content is now available there.

You can view the documentation for v0.12 by clicking this link!

The v0.11 release is a significant milestone for the cert-manager project, and
is full of new features.
We are making a number of changes to our CRDs in a backwards incompatible way,
in preparation for moving into v1beta1 and eventually v1 in the coming
releases:

• Renaming our API group from certmanager.k8s.io to cert-manager.io
• Bumping the API version from v1alpha1 to v1alpha2
• Removing fields deprecated in v0.8 (certificate.spec.acme,
  issuer.spec.http01 and issuer.spec.dns01)
• Renaming annotation prefixes on Ingress & cert-manager resources to use the
  new cert-manager.io prefix, and in some cases acme.cert-manager.io
• Using the status subresource for submitting status updates to the API,
  first introduced in Kubernetes 1.9.
• Tightening use of common name vs DNS name with ACME certificates

We have also switched to using the new [CertificateRequest] based Certificate
issuance implementation, first introduced in alpha in cert-manager v0.9.

These changes enable exciting new integrations points in cert-manager, enabling
new things like:

• External issuer types, such as the [Smallstep Step Issuer]
• Deeper integrations into Kubernetes, with an experimental [CSI driver] that
  can be used to automatically mount signed certificates into pods
• Experimental integration with Istio, allowing you to utilise any of
  cert-manager's configured issuer types/CAs with the [node agent]
• Retrieving certificates without giving cert-manager access to your private
  keys

This is a really exciting time for cert-manager, as these changes have been
made possible by refining our past decisions around API types, and they will
enable us to push ahead with many new features in the project.

Important information

With all of these great changes, there is also work to do.

The changes to our CRD resources mean that upgrading requires more manual
intervention than in previous releases.

It's recommended that you backup and completely uninstall
cert-manager
before re-installing the v0.11 release.

You will also need to manually update all your backed up cert-manager resource
types to use the new apiVersion setting.

A table of resources and their old and new apiVersions:

You must also make sure to update all references to cert-manager in annotations to their
new prefix:

Contributors

This release has seen code contributions from a number of people in the
community 🎉

• Adam Kunicki
• Alpha
• Brian Hong
• Dan Farrell
• Dig-Doug
• Galo Navarro
• Ingo Gottwald
• James Munnelly
• JoshVanL
• Kevin Lefevre
• Lachlan Cooper
• Michel Blankleder
• Toni Menzel
• Wellington F Silva
• Woz
• dulltz

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

Renamed API group

Due to new policies in the upstream Kubernetes project, we have renamed the
API group from certmanager.k8s.io to cert-manager.io.

This is a breaking change to our API surface as mentioned above, but it
is a long time coming. The original k8s.io suffix was used when the project
first started as there was not official guidance or information on how
ThirdPartyResources should be structured. Now that this area of the
Kubernetes project has evolved further, we're retrospectively changing this to
conform with the new requirements.

Moving to v1alpha2

When cert-manager first started, we defined our APIs based on what we thought
made sense for end-users.

Over time, through gathering feedback and monitoring the way users are actually
using cert-manager, we've identified some issues with our original API design.

As part of the project moving towards v1, we've identified certain areas of our
APIs that are not fit for purpose.

In order to begin the process of moving towards v1, we first deprecated a
number of fields in our v1alpha1 API. We've now dropped these API fields
in v1alpha2, in preparation for declaring this new API as v1beta1 in the
coming releases.

New CertificateRequest resource type

The activation of CertificateRequest controllers are no longer behind a
feature and are now instead enabled by default. This means that when requesting
certificates using the Certificate resource the CertificateRequest resource
will be used as the default and only way to honour the request. The addition of
this resource introduces the ability for much greater extension points to
cert-manager, notably out-of-tree issuers, istio integrations, and experimental
tooling such as a CSI driver. You can read more about the motivation and design
of this resource in the enhancement
document.

This change should cause no disruption to how end users interact with
cert-manager, with the exception of debugging now requiring this resource to be
inspected also.

Support for out-of-tree issuer types

With the graduation of the CertificateRequest resource, cert-manager now
supports out-of-tree issuers by default and treats them the same as any other
core issuer. This process is facilitated by the addition of the group field on
issuer references inside your Certificate and CertificateRequest resources.

If you're interested in implementing your own out-of-tree issuer, or if there
is a provider you would like see implemented, feel free to reach out either
through a GitHub
issue
or send us a message in the #cert-manager channel on Kubernetes
Slack!

New fields on Certificate resources

This release includes a new field URISANs on the Certificate resource. With
this, you can specify unique resource identifier URLs as subject alternative
names on your certificates. This addition unblocks development for an istio
integration where mTLS can be configured using cert-manager as the backend and
in turn opens up all cert-manager issuer types as valid certificate providers in
your istio PKI.

Improved ACME Order controller design

Some users may have noticed issues with the 'Order' resource not automatically
detecting changes to their configure 'solvers' on their Issuer resources.

In v0.11, we've rewritten the ACME Order handling code to:

1. better handle updates to Issuers during an Order
2. improve ACME API usage - we now cache more information about the ACME Order
   process in the Kubernetes API, which allows us to act more reliably and
   without causing excessive requests to the ACME server.

No longer generating 'temporary certificates' by default

Previously, we have issued a temporary certificate when a Certificate resource
targeting an ACME issuer has been created. This would later be overridden once
the real signed certificate has been issued. The reason for this behaviour was
to facilitate compatibility with ingress-gce however, many users have had trouble
with this in the past and has led to lots of confusion - namely where
applications would need restarting to take on the signed certificate rather than
the temporary.

In this release, no temporary certificates will be created unless explicitly
requested. This can be done using the annotation
"cert-manager.io/issue-temporary-certificate": "true on Certifcate
resources.

We've additionally changed the behaviour of ingress-shim to now add this new
annotation to Certificate resources if
"acme.cert-manager.io/http01-edit-in-place" is present on the Ingress
resource.

Changelog

Action Required

• Rename certmanager.k8s.io API group to cert-manager.io (#2096, @munnerz)
• Move Order and Challenge resources to the acme.cert-manager.io API group (#2093, @munnerz)
• Move v1alpha1 API to v1alpha2 (#2087, @munnerz)
• Allow controlling whether temporary certificates are issued using a new annotation "certmanager.k8s.io/issue-temporary-certificate"
  on Certificate resources. Previously, when an ACME certificate was requested, a temporary certificate would be issued in order
  to improve compatibility with ingress-gce. ingress-shim has been updated to automatically set this annotation on managed Certificate
  resources when using the 'edit-in-place' annotation, but users that have manually created their Certificate resources will need to
  manually add the new annotation to their Certificate resources. (#2089, @munnerz)

Other Notable Changes

• Change the default leader election namespace to 'kube-system' instead of the same namespace as the cert-manager pod, to avoid multiple copies of cert-manager accidentally being run at once (#2155, @munnerz)
• Adds URISANs field to Certificate.Spec resource. (#2085, @JoshVanL)
• Move status to a CRD Subresource (#2097, @JoshVanL)
• Enables supporting out of tree issuers with ingress annotations (#2105, @JoshVanL)
• Bump Kubernetes dependencies to 1.16.0 (#2095, @munnerz)
• Adds Certificate conformance suite (#2034, @JoshVanL)
• Build using Go 1.13.1 (#2114, @munnerz)
• Adds Kubernetes authentication type for Vault Issue (#2040, @JoshVanL)
• Service account annotation support in Helm chart (#2086, @serialx)
• Update AWS Go SDK to 1.24.1 to support IAM Roles for Service Accounts (#2083, @serialx)
• Remove deprecated API fields and functionality (#2082, @munnerz)
• Update hack/ci/run-dev-kind.sh script to use the right path of cert-manager charts. (#2074, @srvaroa)
• Simplify, improve and rewrite the acmeorders controller (#2041, @munnerz)

The v0.11.0-beta.0 is a pre-release version. It makes a number of significant changes to our CRDs, including:

• Renaming our API group from certmanager.k8s.io to cert-manager.io
• Bumping the API version from v1alpha1 to v1alpha2
• Removing fields deprecated in v0.8 (certificate.spec.acme,
  issuer.spec.http01 and issuer.spec.dns01)
• Renaming annotation prefixes on Ingress & cert-manager resources to use the
  new cert-manager.io prefix, and in some cases acme.cert-manager.io
• Using the status subresource for submitting status updates to the API,
  first introduced in Kubernetes 1.9.
• Tightening use of common name vs DNS name with ACME certificates

You can read the draft release notes here: https://github.com/jetstack/cert-manager/blob/release-0.11/design/release-notes/release-0.11/draft-release-notes.md

The recommended upgrade procedure is to backup your resources and completely uninstall and reinstall cert-manager.

You can read provisional upgrade notes here: https://docs.cert-manager.io/en/release-0.11/tasks/upgrading/upgrading-0.10-0.11.html

We'd really appreciate any feedback on the upgrade procedure and any issues or tips you may run into.

There may be additional beta releases of v0.11 prior to the final v0.11 release being cut, otherwise it is due to be released mid next week.

The v0.11.0-alpha.0 is a pre-release version. It makes a number of significant changes to our CRDs, including:

1. changing the API group to cert-manager.io from certmanager.k8s.io
2. bumping the API version from v1alpha1 to v1alpha2
3. removing the deprecated certificate.spec.acme, issuer.spec.acme.http01 and issuer.spec.acme.dns01 fields

The recommended upgrade procedure is to backup your resources and completely uninstall and reinstall cert-manager.

You can read provisional upgrade notes here: https://github.com/jetstack/cert-manager/blob/master/docs/tasks/upgrading/upgrading-0.10-0.11.rst

We'd really appreciate any feedback on the upgrade procedure and any issues or tips you may run into.

There will be additional alpha releases of v0.11 prior to the final v0.11 release being cut.

This release contains no functional changes over the recent v0.10.0 release.

The notable change is bumping the Golang version used to build cert-manager to Go 1.12.10, to address a few recent CVEs.

It's recommended all v0.10.0 users upgrade to v0.10.1 as soon as possible.

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 utilise the new way to specify
configuration.

A number of steps have been taken in our own codebase 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 onwards).

Action Required

No special actions are required as part of this release.

Changelog

General

• Add DisableDeprecatedACMECertificates feature gate to disable the old deprecated ACME config 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' and 'status' 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

• Use dedicated controller for webhook TLS bootstrapping (#1993, @munnerz)

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 if issuerRef.group is set in order to support out-of-tree Issuer types (#1949, @munnerz)
• Adds CertificateRequest FailureTime. The Certificate controller will re-try failed CertificateRequests 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)

Changelog since v0.9.0

• Fix concurrent map write panic in certificates controller (#1980, @munnerz)
• Fix panic when an ACME Order fails (#1965, @munnerz)

The v0.9 release is one of our biggest yet, packed with new features and bug
fixes!

The introduction of the new CertificateRequest resource type is significant as
it is a step towards where we want to be for 1.0, defining an API specification
for Certificates and allowing anyone to implement their own issuers and CAs as
first class citizens.

This release includes changes from:

• Aaron Gershman
• Aled James
• Artem Yarmoluk
• Carlos Panato
• Chris Abiad
• Christopher Abiad
• Crystal-Chun
• Dan
• Dobes Vandermeer
• Hans Kristian Flaatten
• Hays Clark
• Ivan Wallis
• James Munnelly
• Joshua Van Leeuwen
• Kevin Woo
• Lachlan Cooper
• Louis Taylor
• Michael Cristina
• Michael Tsang
• PirateBread
• Qiu Yu
• Sergej Nikolaev
• Solly Ross
• Stefan Kolb
• Steven Tobias
• Stuart Hu
• Till Wiese
• kfoozminus

Notable Items

New CertificateRequest Resource

A new resource has been introduced - CertificateRequest - that is used to
request certificates using a raw x509 certificate signing request. This resource
is not typically used by humans but rather by other controllers or services. For
example, the Certificate controller will now create a CertificateRequest
resource to resolve its own Spec.

Controllers to resolve CertificateRequests are currently disabled by default
and enabled via the feature gate CertificateRequestControllers. This feature
is currently in Alpha and only the CA issuer has been implemented.

This resource is going to enable out of tree, external issuer controllers to
resolve requests. Other issuer implementations and details on how to develop an
out of tree issuer will follow in later releases. You can read more on the
motivations and road map in the enhancement proposal or how this resource is
used in the docs.

DNS Zones support for ACME challenge solver selector

A list of DNS zones can now be added to the ACME challenge solver selector. The
most specific DNS zone match specified here will take precedence over other DNS
zone matches, so a solver specifying sys.example.com will be selected over one
specifying example.com for the domain www.sys.example.com. If multiple
solvers match with the same dnsZones value, the solver with the most matching
labels in matchLabels will be selected. If neither has more matches, the solver
defined earlier in the list will be selected.

Certificate Readiness Prometheus Metrics

Cert-manager now exposes Prometheus metrics on Certificate ready statuses as
certmanager_certificate_ready_status. This is useful for monitoring
Certificate resources to ensure they have a Ready=True status.

Prometheus Operator ServiceMonitor

Support has been added to include a Prometheus ServiceMonitor for cert-manager
in the helm chart. This enables monitoring of cert-manager when in conjunction
with the Prometheus Operator.
This is disabled by default but can be enabled via the helm configuration.

ACMEv2 POST-as-GET

We have now switched to use the new POST-as-GET feature that was introduced
into the latest version of the ACME spec a few months ago.

If you are running your own ACME server, please ensure it supports POST-as-GET
as we no longer supported the old behaviour.

ACME Issuer Solver Pod Template

The ACME Solver Pod Spec now exposes a template that can be used to change
metadata about that pod. Currently, a template will expose labels, annotations,
node selector, tolerations, and affinity. This is useful when running
cert-manager in multi-arch clusters, or when you run workloads across different
types of nodes and need to restrict where the acmesolver pod runs.

Action Required

Length limit for Common Names

Common names with a character length of over 63 will be rejected during
validation. This is due to the upper limit being detailed in RFC 5280.

Distroless Cert-Manager Base Images

For each container, cert-manager ships with the base image
'gcr.io/distroless/static' which is a minimal image that includes no binaries.
Users who want to debug from within the cert-manager pod will need to attach an
additional container with their debug utilities to the pod's namespace.

CSRs in Order Resources now PEM Encoded

CSRs in Order resources have previously been incorrectly DER encoded due to an
error in implementation. This has now been corrected to PEM encoding. Current
orders that were created with a previous version of cert-manager will fail to
validate and so will be recreated. This should resume the order normally.

Changelog

General

• Reduce cert-manager's RBAC permissions (#1658, @munnerz)
• commented-out extraArg for enable-certificate-owner-ref (#1828, @aegershman)
• Validate that Certificates in a namespace have unique secretName (#1689, @cheukwing)
• Feature addition: Support for PKCS#8 keys. (#1308, @Crystal-Chun)
• Add the removal of certificates when no longer required by the owner ingress (#1705, @cheukwing)
• Fix bug causing ECDSA certificates to be issued using 2048-bit RSA private keys (#1757, @munnerz)
• Updated the labels in the helm charts to use the newer ones. (#1769, @cpanato)
• Allow disabling issuing temporary certificates with feature flag --feature-gates=IssueTemporaryCertificate=false (#1764, @gordonbondon)
• Switch to using distroless for base images (#1663, @munnerz)
• Limit length for CommonName to 63 bytes (#1818, @cheukwing)

ACME Issuer

• Properly encode the CSR field on Order resources as PEM data instead of DER (#1884, @munnerz)
• Fire informational Event if an ACME solver cannot be chosen for a domain on an Order (#1856, @munnerz)
• Fix bug with auto-generated Order names being longer than 63 characters (#1765, @cheukwing)
• Fix a panic when a misconfigured Issuer is used for HTTP01 challenge solving (#1758, @munnerz)
• Fix a bug where the logic to select a solver would always return the last solver and may return the wrong kind of solver for the challenge that it returned. (#1717, @dobesv)
• Fix indentation on ACME setup examples (#1785, @lachlancooper)
• Fix a the logic to select the most specific solver from an issuer if multiple matched (#1715, @dobesv)
• Adds support for nodeSelector and tolerations in podTemplate.spec (#1803, @cheukwing)
• support azure non-public regions (#1830, @stuarthu)
• Fix issue causing challenge controller to attempt to list Secrets across all namespaces even when --namespace is specified (#1849, @munnerz)
• Adds the handling of updates to the spec.acme.email field in Issuers (#1763, @cheukwing)
• Fix issue with private managed-zone being picked in CloudDNS (#1704, @cheukwing)
• Expose pod template for the ACME issuer solver pod (#1749, @JoshVanL)
• Ingress skips updating Certificate resource if already exists and not owned (#1670, @cheukwing)
• Add support for ACMEv2 POST-as-GET (#1648, @munnerz)
• Fix incorrect handling of issuewild tag when verifying CAA (#1777, @cheukwing)
• Add support for selecting ACME challenge solver to use by specifying 'dnsZones' in the selector (#1806, @munnerz)
• Use proxy environment variables in self-check request (#1850, @kinolaev)

Venafi Issuer

• Venafi: use vCert v4.1.0 (#1827, @munnerz)
• Bump Venafi vcert dependency to latest version (#1754, @munnerz)

Webhook

• cert-manager-webhook secret exists in cert-manager ns (#1791, @jetstack-bot)
• Support CRD conversion webhooks in the CA injector controller. (#1505, @DirectXMan12)

CA Issuer

• Adds CSR signing to CA issuer (#1835, @JoshVanL)

CertificateRequest

• Adds CertificateRequest resource (#1789, @JoshVanL)
• Adds CA issuer controller to resolve CertificateRequests where CA is the issuer reference (#1836, @JoshVanL)
• Adds Sign interface to Issuers (#1807, @JoshVanL)
• Adds group to issuerRef in CertificateRequest resources to distinguish resource ownership of incoming CertificateRequests so enabling full external issuer support. (#1860, @JoshVanL)

Documentation

• Adds Design and Proposals page to website docs (#1876, @JoshVanL)
• Adds CertificateRequest proposal (#1866, @JoshVanL)

Monitoring

• Prometheus metrics for deleted Certificates are cleaned up (#1681, @cheukwing)
• Adds ControllerSyncCallCount prometheus metric to count sync calls from each controller (#1692, @cheukwing)
• Add support for Prometheus Operator ServiceMonitor object in Helm Chart (#1761, @Starefossen)
• Add Prometheus metrics for tracking Certificate readiness (#1811, @cheukwing)

Release notes TBD, view draft here

Changelog since v0.8.0

• cert-manager-webhook secret exists in cert-manager ns (#1753, @kevinawoo)
• Fix indentation on ACME setup examples (#1785, @lachlancooper)
• Fix ECDSA certificate issuance with ACME issuer (#1757, @munnerz)
• Fix panic in HTTP01 solver if ingress field is not specified (#1758, @munnerz)
• Fix solver selection logic to return the selected solver rather than always returning the last one (#1717, @dobesv)
• Fix logic to select the solver that has the most labels (#1715, @dobesv)

Following on from the v0.7.x releases and a series of pre-release candidates,
cert-manager v0.8.0 is available at last!

This release packs in a tonne of stability improvements, as well as a whole load
of new features 😀

As part of this release, we're updating our API format in order to better
support the 1.0 release, which we hope to reach within the next few months.
This has been accomplished in a backwards-compatible for now, to make the
upgrade process easier, especially for users that manage large numbers of
certificate resources.

As well as the new release, we've also finally created a project logo!
For those of you who are attending KubeCon EU, we'll be handing out stickers
at the Jetstack booth from tomorrow onwards!

Action required

The deployment manifests have now moved from being a part of our GitHub
repository and are now published alongside each image tag. Please double
check the installation guide for more information on where the manifests
can now be found. This change does not affect the Helm chart!

New ACME configuration format

As part of stabilising our API surface, we've made a change to the way
you configure your ACME based certificates.

Instead of Certificate resources containing an extra certificate.spec.acme
field, which is only relevant for ACME certificates, the configuration has now
moved over to the Issuer resource instead. More details on this change can be
found in the upgrade notes.

OpenShift installation instructions

In order to make it easier for users to run cert-manager on platforms other
than Kubernetes, we've improved our OpenShift support, including an official
installation guide for users of OpenShift.

If you use OpenShift in your organisation, check out the getting started section
for more information on how to get up and running!

Webhook based ACME DNS01 solver

Over the last year and a half, we've had more than 15 pull requests to add new
ACME DNS01 providers to our codebase. It's been brilliant to see such vibrant
community involvement, however it's become infeasible for us to continue to
accept, test and maintain such a rapidly growing matrix of providers.

As a result, we've put together a new 'webhook' DNS01 solver type.
This allows you to create and install your own DNS01 providers without having
to make changes in cert-manager itself.

You can see an example repository to get started building your own over in the
cert-manager-webhook-example repo on GitHub.

This is a new and experimental feature, however we're excited to see the community
move to this new model of extending cert-manager.

Switch to structured logging

As the project has grown, we've also increased the verbosity and frequency of our log messages.
Over time, this has become difficult to manage and work with, and so with the v0.8 release
we have begun the process of switching over our codebase to structured logging.

This should make it far easier to index, search and grep through log messages that cert-manager
emits.

Your feedback here is really valuable, so please open issues and comment on Slack if you
have any issues!

Changelog

• make email address an optional field in ACME issuers (#1483, @DanielMorsing)
• Fix bug when handling resources that have lastTransitionTime set to null (#1628, @munnerz)
• Allow Openshift to install cert-manager chart (#1395, @JGodin-C2C)
• Update documentation for new 'solvers' field (#1623, @munnerz)
• Fix issue where ingress-shim would not clear old configuration when migrating to the new 'solvers' field (#1620, @munnerz)
• Add new issuer.spec.acme.solvers field that replaces certificate.spec.acme'in order to make all certificate resources portable between issuer types. The previously syntax is still supported to allow easy migration to the new configuration format. (#1450, @munnerz)
• Fixes additionalPrinterColumn formatting for Certificate resources (#1616, @munnerz)
• Fix update loop in certificates controller and add additional debug logging (#1602, @munnerz)
• Automatically retry expired Challenge resources (#1603, @munnerz)
• Build under MacOS. (#1601, @michaelfig)
• Disable the CAA check by default, and introduce a new --feature-gates=ValidateCAA=true option to enable it (#1585, @munnerz)
• Improve error handling when ACME challenges fail to Present or CleanUp (#1597, @munnerz)
• • add static label for solver identification to allow usage of custom service (#1575, @christianhuening)
• Fix issues running the cainjector controller on Kubernetes 1.9 (#1579, @munnerz)
• Fix upgrade bug where lastTransitionTime may be set to nil, rendering cert-manager inoperable without manual intervention (#1576, @munnerz)
• Add webhook based DNS01 provider (#1563, @munnerz)
• Add DNS01 provider conformance test suite (#1562, @munnerz)
• • fix typo in the deployment template (#1546, @cpanato)
• Automatically generate LICENSES file (#1549, @munnerz)
• Switch to go modules for dependency management (#1523, @munnerz)
• Bump to use Go 1.12 (#1429, @munnerz)
• use authoritative nameservers for CAA checks (#1521, @DanielMorsing)
• Update certificate if issuer changes (#1512, @lentzi90)
• also whitelist ipv6 (#1497, @mdonoughe)
• Set default acmesolver image based on arch (#1494, @lentzi90)
• Improve logging in ACME HTTP01 solver (#1474, @munnerz)
• Run metrics server on cert-manager instances that have not been elected as leader (#1482, @kragniz)
• Switch to structured logging using logr (#1409, @munnerz)
• fixing the quickstart documentation to use the new helm chart repo charts.jetstack.io (#1468, @BradErz)
• Removes need for hostedZoneName to be specified. Uses discovered DNS zone name instead. (#1466, @logicfox)

This should be the final pre-GA release of v0.8, pending no new issues being raised this week.

Manual testing and feedback from users on v0.8.0-alpha.0 showed consistent, successful results barring a fix that was made in #1620.

As part of this release, we will no longer be publishing 'static deployment manifests' as part of the repository. Instead, these will be published via GitHub Releases.

Documentation changes will be made this week to account for the new options, including updated deployment instructions for users of the 'static deployment manifests'.

Thanks to all those that have tried the v0.8 pre-releases 😄

Changelog since v0.8.0-alpha.0

• make email address an optional field in ACME issuers (#1483, @DanielMorsing)
• Fix bug when handling resources that have lastTransitionTime set to null (#1628, @munnerz)
• Allow Openshift to install cert-manager chart (#1395, @JGodin-C2C)
• Update documentation for new 'solvers' field (#1623, @munnerz)
• Fix issue where ingress-shim would not clear old configuration when migrating to the new 'solvers' field (#1620, @munnerz)