Automatically provision and manage TLS certificates in Kubernetes
APACHE-2.0 License
Bot releases are visible (Hide)
Published by jetstack-release-bot over 2 years ago
1.6.3 is a minor release rebuilding cert-manager 1.6 using the latest version of Go. This eliminates a few security vulnerabilities which have accumulated in Go since the last release.
We don't believe any of those vulnerabilities were practically exploitable or relevant to cert-manager, but we decided to rebuild to keep up to date anyway.
Published by jetstack-release-bot over 2 years ago
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
Version 1.7.1 fixes a bug which was discovered in 1.7.0 relating to the new additionalOutputFormat
feature.
additionalOutputFormats
is now correctly validated at admission time, and no longer only validated if the privateKey
field of the Certificate is set. The Webhook component now contains a separate feature set.AdditionalCertificateOutputFormats
feature gate (disabled by default) has been added to the webhook. This gate is required to be enabled on both the controller and webhook components in order to make use of the Certificate's additionalOutputFormat
feature. (#4816, @JoshVanL)Published by jetstack-release-bot over 2 years ago
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
Version 1.7 brings new private key output formats, configuration improvements for the webhook, some long-awaited code cleanup, a fix for ingress class semantics and a bunch of other changes.
⚠ Following their deprecation in version 1.4, the cert-manager API versions v1alpha2, v1alpha3, and v1beta1 have been removed. You must ensure that all cert-manager custom resources are stored in etcd at version v1 and that all cert-manager CustomResourceDefinition
s have only v1 as the stored version before upgrading.
Since release 1.7, cmctl
can automatically migrate any deprecated API resources. Please download cmctl-v1.7.0
and read Migrating Deprecated API Resources for full instructions.
In 1.7, we have reverted a change that caused a regression in the ACME Issuer. Before 1.5.4, the Ingress created by cert-manager while solving an HTTP-01 challenge contained the kubernetes.io/ingress.class
annotation:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: istio # The `class` present on the Issuer.
After 1.5.4, the Ingress does not contain the annotation anymore. Instead, cert-manager uses the ingressClassName
field:
apiVersion: networking.k8s.io/v1
kind: Ingress
spec:
ingressClassName: istio # 🔥 Breaking change!
This broke many users that either don't use an Ingress controller that supports the field (such as ingress-gce and Azure AGIC), as well as people who did not need to create an IngressClass previously (such as with Istio and Traefik).
The regression is present in cert-manager 1.5.4, 1.6.0, 1.6.1. It is only present on Kubernetes 1.19+ and only appears when using an Issuer or ClusterIssuer with an ACME HTTP-01 solver configured.
In 1.7, we have restored the original behavior which is to use the annotation. We will also backport this fix to 1.5.5 and 1.6.2, allowing people to upgrade safely.
Most people won't have any trouble upgrading from a version that contains the regression to 1.7.0, 1.6.2 or 1.5.5. If you are using Gloo, Contour, Skipper, or kube-ingress-aws-controller, you shouldn't have any issues. If you use the default "class" (e.g., istio
for Istio) for Traefik, Istio, Ambassador, or ingress-nginx, then these should also continue to work without issue.
If you are using Traefik, Istio, Ambassador, or ingress-nginx and you are using a non-default value for the class (e.g., istio-internal
), or if you experience any issues with your HTTP-01 challenges please read the notes on Ingress v1 compatibility.
As part of the work to remove deprecated APIs cert-manager CustomResourceDefinition
s no longer require a conversion webhook. The related change in cert-manager CustomResourceDefinition
specs results in invalid CustomResourceDefinition
configurations for users who are upgrading to cert-manager 1.7 using kubectl apply --server-side=true -f <manifests>
. This can be solved either by performing the upgrade with client side apply or by manually patching the managed fields of cert-manager CustomResourceDefinitions
:
crds=("certificaterequests.cert-manager.io" "certificates.cert-manager.io" "challenges.acme.cert-manager.io" "clusterissuers.cert-manager.io" "issuers.cert-manager.io" "orders.acme.cert-manager.io")
for crd in "${crds[@]}"; do
manager_index="$(kubectl get crd "${crd}" --show-managed-fields --output json | jq -r '.metadata.managedFields | map(.manager == "cainjector") | index(true)')"
kubectl patch crd "${crd}" --type=json -p="[{\"op\": \"remove\", \"path\": \"/metadata/managedFields/${manager_index}\"}]"
done
(Thanks to @stevehipwell for the above patch commands!)
See the original GitHub issue cert-manager#4831
In 1.7 the cert-manager API versions v1alpha2, v1alpha3, and v1beta1, that were deprecated in 1.4, have been removed from the custom resource definitions (CRDs). As a result, you will notice that the YAML manifest files are much smaller.
In this release we have added a new sub-command to the cert-manager CLI (cmctl upgrade migrate-api-version
), which you SHOULD run BEFORE upgrading cert-manager to 1.7. Please read [Removing Deprecated API Resources] for full instructions.
additionalOutputFormats
is a field on the Certificate spec
that allows specifying additional supplementary formats of issued certificates and their private key. There are currently two supported additional output formats: CombinedPEM
(the PEM-encoded private key followed by the certificate chain) and DER
(the DER-encoded private key only). Any combination of output formats can be requested for the same certificate. Read Additional Certificate Output Formats for more details and thanks to @seuf for getting this across the line!
This is the first version of cert-manager which relies on Server-Side Apply. We use it to properly manage the annotations and labels on TLS secrets. For this reason cert-manager 1.7 requires at least Kubernetes 1.18 (see Supported Releases for further compatibility details).
In this release we introduce a new configuration file for the cert-manager-webhook. Instead of configuring the webhook using command line flags, you can now modify the webhook Deployment to mount a ConfigMap containing a configuration file. Read the WebhookConfiguration Schema for more information.
In future releases we will introduce configuration files for the other cert-manager components: the controller and the cainjector.
In a future release, we'll remove the use of bazel
for building and testing cert-manager, with the aim of making it as easy as possible for anyone to contribute and to get involved with the cert-manager project.
The work is ongoing, but for now we've ensured that cert-manager 1.7 can be built with go build
, and that all unit tests can be run with go test ./cmd/... ./internal/... ./pkg/...
.
Thanks again to all open-source contributors with commits in this release, including:
Thanks as usual to @coderanger for helping people out on the #cert-manager
Slack channel; it's a huge help and much appreciated.
In addition, the following cert-manager maintainers were involved in this release:
--acme-http01-solver-nameservers
flag to enable custom nameservers usage for ACME HTT01 challenges propagation checks. (#4287, @Adphi)cmctl upgrade migrate-api-version
to ensure all CRD resources are stored at 'v1' prior to upgrading to v1.7 onwards (#4711, @munnerz)additionalOutputFormats
parameter to allow DER
(binary) and CombinedPEM
(key + cert bundle) formats. (#4598, @seuf)prometheus.servicemonitor.honorLabels
, which sets the honor_labels
field of the Prometheus scrape config. (#4608, @thirdeyenick)--enable-profiling
, --profiler-address
CLI flags to configure profiling. Thanks to @bitscuit for help with this! (#4550, @irbekrm)RunWebhookServer
(#4702, @devholic)cmctl version
to erroneously display the wrong webhook pod versions when older failed pods are present. (#4615, @johnwchadwick)cmctl
that prevented displaying the Order resource with cert-manager 1.6 when running cmctl status certificate
. (#4569, @maelvls)kubernetes.io/ingress.class
annotation instead of the spec.ingressClassName
in created Ingress resources. (#4762, @jakexks)cmctl experimental install
command now uses the cert-manager namespace. This fixes a bug which was introduced in release 1.6 that caused cert-manager to be installed in the default namespace. (#4763, @wallrj)clock_time_seconds_gauge
metric which returns the current clock time, based on seconds since 1970/01/01 UTC (#4640, @JoshVanL)dns01-self-check-nameservers
flag. Use --dns01-recursive-nameservers
instead. (#4551, @irbekrm)v1beta1
form the webhook's admissionReviewVersions
as cert-manager no longer supports v1.16 (#4639, @JoshVanL)Published by jetstack-release-bot over 2 years ago
In 1.6.2, we have reverted a change present in 1.6.0 and 1.6.1 that caused a regression in the ACME Issuer. In 1.6.0 and 1.6.1, the Ingress created by cert-manager while solving an HTTP-01 challenge contained the kubernetes.io/ingress.class
annotation:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: istio # The `class` present on the Issuer.
After 1.5, the Ingress does not contain the annotation anymore. Instead, cert-manager uses the ingressClassName
field:
apiVersion: networking.k8s.io/v1
kind: Ingress
spec:
ingressClassName: istio # 🔥 Breaking change!
This broke many users that either don't use an Ingress controller that supports the field (such as ingress-gce and Azure AGIC), as well as people who did not need to create an IngressClass previously (such as with Istio and Traefik).
The regression is present in cert-manager 1.5.4, 1.6.0, and 1.6.1. It is only present on Kubernetes 1.19+ and only appears when using an Issuer or ClusterIssuer with an ACME HTTP-01 solver configured.
In 1.6.2, we have restored the original behavior which is to use the annotation. This patch is also available in 1.5.5 and in 1.7.0.
Most people won't have any trouble upgrading from 1.6.0 or 1.6.1 to 1.6.2. If you are using Gloo, Contour, Skipper, or kube-ingress-aws-controller, you shouldn't have any issues. If you use the default "class" (e.g., istio
for Istio) for Traefik, Istio, Ambassador, or ingress-nginx, then these should also continue to work without issue.
If you are using Traefik, Istio, Ambassador, or ingress-nginx and you are using a non-default value for the class (e.g., istio-internal
), or if you experience any issues with your HTTP-01 challenges please read the notes on Ingress v1 compatibility.
kubernetes.io/ingress.class
annotation instead of the spec.ingressClassName
in created Ingress resources. (#4785, @jetstack-bot)Nothing has changed.
Nothing has changed.
Nothing has changed.
Published by jetstack-release-bot over 2 years ago
In 1.5.5, we have reverted a change that caused a regression in the ACME Issuer.
Before 1.5.4, the Ingress created by cert-manager while solving an HTTP-01 challenge contained the kubernetes.io/ingress.class
annotation:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: istio # The `class` present on the Issuer.
In 1.5.4, the Ingress does not contain the annotation anymore. Instead, cert-manager uses the ingressClassName
field:
apiVersion: networking.k8s.io/v1
kind: Ingress
spec:
ingressClassName: istio # 🔥 Breaking change!
This broke many users that either don't use an Ingress controller that supports the field (such as ingress-gce and Azure AGIC), as well as people who did not need to create an IngressClass previously (such as with Istio and Traefik).
The regression is present in cert-manager 1.5.4, 1.6.0, 1.6.1. It is only present on Kubernetes 1.19+ and only appears when using an Issuer or ClusterIssuer with an ACME HTTP-01 solver configured.
In 1.5.5, we have restored the original behavior which is to use the annotation. We will also backport this fix to 1.5.5 and 1.6.2, allowing people to upgrade safely.
Most people won't have any trouble upgrading from a version that contains the regression to 1.7.0, 1.6.2 or 1.5.5. If you are using Gloo, Contour, Skipper, or kube-ingress-aws-controller, you shouldn't have any issues. If you use the default "class" (e.g., istio
for Istio) for Traefik, Istio, Ambassador, or ingress-nginx, then these should also continue to work without issue.
If you are using Traefik, Istio, Ambassador, or ingress-nginx and you are using a non-default value for the class (e.g., istio-internal
), or if you experience any issues with your HTTP-01 challenges please read the notes on Ingress v1 compatibility.
ingressClassName
instead of the annotation kubernetes.io/ingress.class
. More details about this regression are available in the 1.7 release notes. (#4783, @maelvls)Published by jetstack-release-bot over 2 years ago
⚠ Following their deprecation in version 1.5, the cert-manager API versions v1alpha2, v1alpha3, and v1beta1 have been removed. You must ensure that all cert-manager custom resources are stored in etcd at version v1 and that all cert-manager CustomResourceDefinition
s have only v1 as the stored version.
Since release 1.7, cmctl
can automatically migrate any deprecated API resources. Please download cmctl-v1.7.0-beta.0
and read Removing Deprecated API Resources for full instructions.
In 1.7 the cert-manager API versions v1alpha2, v1alpha3, and v1beta1 have been removed from the custom resource definitions (CRDs). You will notice that the YAML manifest files are much smaller as a result. These APIs have been deprecated since 1.5.
In this release, we have added a new sub-command to the cert-manager CLI (cmctl upgrade migrate-api-version
), which you SHOULD run BEFORE upgrading cert-manager to 1.7. Please read Removing Deprecated API Resources for full instructions.
This is the first version of cert-manager which relies on Server-Side Apply. We are using it to properly manage the annotations and labels on the TLS Secret. For this reason, cert-manager 1.7 requires at least Kubernetes 1.18.
In this release, we introduce a new configuration file for the cert-manager-webhook. Instead of configuring the webhook using command-line flags, you can now modify the webhook Deployment to mount a ConfigMap containing a configuration file. Read the WebhookConfiguration Schema for more information.
In future releases, we will introduce configuration files for the other cert-manager components: controller-manager and cainjector.
Thanks again to all open-source contributors with commits in this release, including:
And thanks as usual to coderanger for helping people out on the Slack #cert-manager
channel; it's a huge help and much appreciated.
cmctl upgrade migrate
to ensure all CRD resources are stored at 'v1' prior to upgrading to v1.7 onwards (#4711, @munnerz)DER
(binary) and CombinedPEM
(key + cert bundle) formats. (#4598, @seuf)cmctl version
to erroneously display the wrong webhook pod versions when older failed pods are present. (#4616) (#4615, @johnwchadwick)RunWebhookServer
(#4702, @devholic)kubernetes.io/ingress.class
annotation instead of the spec.ingressClassName
in created Ingress resources. (#4762, @jakexks)cmctl experimental install
command now uses the cert-manager namespace. This fixes a bug which was introduced in release 1.6 that caused cert-manager to be installed in the default namespace. (#4763, @wallrj).Values.serviceAnnotations
(#4329, @jwenz723)clock_time_seconds_gauge
metric which returns the current clock time, based on seconds since 1970/01/01 UTC (#4640, @JoshVanL)v1beta1
form the webhook's admissionReviewVersions as cert-manager no longer supports v1.16 (#4639, @JoshVanL)Published by jetstack-release-bot over 2 years ago
⚠ Following their deprecation in version 1.5, the cert-manager APIVersions v1alpha2, v1alpha3, and v1beta1 have been removed.
You must ensure that all cert-manager custom resources are stored in etcd at version v1
and that all cert-manager CustomResourceDefinition
s have only v1 as the stored version.
Since v1.7.0-alpha.1
cmctl
can automatically migrate any deprecated API resources.
Please download cmctl-v1.7.0-alpha.1
(from the Assets section below) and read Removing Deprecated API Resources
for full instructions.
cmctl upgrade migrate-api-version
to ensure all CRD resources are stored at 'v1' prior to upgrading to v1.7 onwards (#4711, @munnerz)DER
(binary) and CombinedPEM
(key + cert bundle) formats. (#4598, @seuf)RunWebhookServer
(#4702, @devholic).Values.serviceAnnotations
(#4329, @jwenz723)Published by jetstack-release-bot almost 3 years ago
Following their deprecation in version 1.5, the cert-manager APIVersions v1alpha2, v1alpha3, and v1beta1 have been removed.
You must ensure that all cert-manager custom resources are stored in etcd at version v1 and all cert-manager CustomResourceDefinition
s have only v1 as the stored version. Please see documentation for how to do this.
cmctl version
to erroneously display the wrong webhook pod versions when older failed pods are present. (#4616) (#4615, @johnwchadwick)clock_time_seconds_gauge
metric which returns the current clock time, based on seconds since 1970/01/01 UTC (#4640, @JoshVanL)v1beta1
form the webhook's admissionReviewVersions as cert-manager no longer supports v1.16 (#4639, @JoshVanL)Published by jetstack-release-bot almost 3 years ago
cmctl
that prevented displaying the Order resource with cert-manager 1.6 when running cmctl status certificate
. (#4572, @maelvls)Nothing has changed.
Nothing has changed.
Published by jetstack-release-bot almost 3 years ago
⚠️ Following their deprecation in version 1.4, the cert-manager APIVersions v1alpha2, v1alpha3, and v1beta1
are no longer served.
This means if your deployment manifests contain any of these API versions, you will not be able to deploy them after upgrading. Our new cmctl
utility or old kubectl cert-manager
plugin can convert old manifests to v1
for you.
⚠️ JKS Keystores now have a minimum password length of 6 characters, as an unintended side effect of upgrading keystore-go from v2 to v4. This was fixed in cert-manager v1.6.1
cmctl
as well as kubectl-cert_manager
(#4523, @JoshVanL)cmctl completion
command for generating shell completion scripts for bash, zsh, fish, and powershell (#4408, @JoshVanL)startupapicheck
post-install hook in the Helm chart now deletes any post-install hook resources left after a previous failed install allowing helm install to be re-run after a previous failure. (#4433, @wallrj)CertificateRequest
s owning Order
s. (#4369, @irbekrm)Published by jetstack-release-bot about 3 years ago
cmctl
as well as kubectl-cert_manager
(#4523, @JoshVanL)cmctl completion
command for generating shell completion scripts for bash, zsh, fish, and powershell (#4408, @JoshVanL)Published by jetstack-release-bot about 3 years ago
Published by jetstack-release-bot about 3 years ago
Published by jetstack-release-bot about 3 years ago
startupapicheck
post-install hook in the Helm chart now deletes any post-install hook resources left after a previous failed install allowing helm install to be re-run after a previous failure. (#4435, @wallrj)Published by jetstack-release-bot about 3 years ago
startupapicheck
post-install hook in the Helm chart now deletes any post-install hook resources left after a previous failed install allowing helm install to be re-run after a previous failure. (#4433, @wallrj)Published by jetstack-release-bot about 3 years ago
Published by jetstack-release-bot about 3 years ago
The CRDs for the cert-manager v1beta1 API were mistakenly changed in cert-manager v1.5.0. If you
installed the CRDs for v1.5.0, you should upgrade your CRDs to v1.5.1.
The only affected API version is v1beta1, so if you're using the latest version - v1 - you won't
be affected by the CRD changes. It's worth upgrading to v1 in any case, since v1alpha2, v1alpha3 and
v1beta1 are all deprecated and will be removed in a future release.
Published by jetstack-release-bot about 3 years ago
cert-manager 1.5 is the first release to support Kubernetes 1.22.
Note: cert-manager API versions v1alpha2
, v1alpha3
and v1beta1
that were deprecated in 1.4 will no longer be served in 1.6. If your cert-manager deployment was created before 1.0 and/or any cert-manager resources were created using any of the deprecated APIs, please ensure the resources and CRDs are updated before upgrading to 1.6, see the docs.
ctl experimental create certificatesigningrequest
for creating a Kuberenetes CertificateSigningRequest based upon a cert-manager Certificate manifest file (#4106, @JoshVanL)--feature-gates=ExperimentalCertificateSigningRequestControllers=true
(#4112, @JoshVanL)--feature-gates=ExperimentalCertificateSigningRequestControllers=true
(#4100, @JoshVanL)--feature-gates=ExperimentalCertificateSigningRequestControllers=true
(#4103, @JoshVanL)--feature-gates=ExperimentalCertificateSigningRequestControllers=true
(#4108, @JoshVanL)kubectl cert-manager x install
command is added (#4138, @inteon)tls
block or with certificateRef
left empty. (#4293, @maelvls)kubectl.kubernetes.io/
, fluxcd.io
, argocd.argoproj.io
are now excluded by default. (#4251, @irbekrm)experimental.cert-manager.io/ca
annotation set. (#4143, @JoshVanL)