Automatically provision and manage TLS certificates in Kubernetes
APACHE-2.0 License
Bot releases are visible (Hide)
Published by jetstack-release-bot almost 2 years ago
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
cert-manager v1.9.2
is a bug fix release which fixes an issue where CertificateRequests marked as InvalidRequest did not properly trigger issuance failure handling leading to 'stuck' requests, and a problem which prevented the Venafi Issuer from connecting to TPP servers where the vedauth
API endpoints were configured to accept client certificates.
It is also compiled with a newer version of Go 1.18 (v1.18.8
) which fixes some vulnerabilities in the Go standard library.
v1.9.1
vedauth
API endpoints are configured to accept client certificates. (Note: This does not mean that the Venafi Issuer supports client certificate authentication).Published by jetstack-release-bot almost 2 years ago
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
Version 1.9.2-beta.0 is a pre-release of the forthcoming 1.9.2 patch release to allow wider community testing of the following bug fixes and updates before we make the patch release generally available.
Published by jetstack-release-bot almost 2 years ago
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
Version 1.11.0-alpha.0 is the first alpha release of 1.11 and is not suitable for production use.
golang.org/x/text
vulnerability (#5562, @SgtCoDFish)Published by jetstack-release-bot about 2 years ago
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
Version 1.10 adds a variety of quality-of-life fixes and features including improvements to the test suite.
This change is only relevant if you install cert-manager using Helm or the static manifest files. v1.10.0
changes the names of containers in pods created by cert-manager.
The names are changed to better reflect what they do; for example, the container in the controller pod had its name changed from cert-manager
to cert-manager-controller
,
and the webhook pod had its container name changed from cert-manager
to cert-manager-webhook
.
This change could cause a break if you:
If both of these are true, you may need to update your automation before you upgrade.
In cert-manager 1.10 the secure computing (seccomp) profile for all the Pods is set to RuntimeDefault. (See cert-manager#5259.) The securityContext fields of the Pod are set as follows:
...
# ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
securityContext:
seccompProfile:
type: RuntimeDefault
...
On some versions and configurations of OpenShift this can cause the Pod to be rejected by the Security Context Constraints admission webhook.
Read full release notes to learn if this might affect you and how to fix it.
issuer_name
, issuer_kind
and issuer_group
labels to certificate_expiration_timestamp_seconds
, certmanager_certificate_renewal_timestamp_seconds
and certmanager_certificate_ready_status
metrics (#5461, @dkulchinsky)cert-manager.io/private-key-secret-name
. This resolves an issue whereby a request would never be signed when the target Secret was not created or was misconfigured before the request. (#5336, @JoshVanL)experimental.cert-manager.io/private-key-secret-name
. This resolves an issue whereby a request would never be signed when the target Secret was not created or was misconfigured before the request.commonLabels
which gives you the capability to add the same label on all the resource deployed by the chart. (#5208, @thib-mary)experimental.cert-manager.io/private-key-secret-name
doesn't exist. (#5323, @JoshVanL)accessKeyID
or secretAccessKeyID
. (#5339, @JoshVanL)cmctl
and kubectl cert-manager
now report their actual versions instead of "canary", fixing issue #5020 (#5022, @maelvls)1.19
(#5466, @lucacome).bazel
and .bzl
files from cert-manager now that bazel has been fully replaced (#5340, @SgtCoDFish)v0.25.2
. (#5456, @lucacome)cert-manager
being the container name. (#5410, @rgl)Thank you to the following community members who had a merged PR for this version - your contributions are at the heart of everything we do!
Thanks also to the following maintainers who worked on cert-manager 1.10:
Published by jetstack-release-bot about 2 years ago
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
Version 1.10 adds a variety of quality-of-life fixes and features including improvements to the test suite.
issuer_name
, issuer_kind
and issuer_group
labels to certificate_expiration_timestamp_seconds
, certmanager_certificate_renewal_timestamp_seconds
and certmanager_certificate_ready_status
metrics (#5461, @dkulchinsky)cert-manager.io/private-key-secret-name
. This resolves an issue whereby a request would never be signed when the target Secret was not created or was misconfigured before the request. (#5336, @JoshVanL)experimental.cert-manager.io/private-key-secret-name
. This resolves an issue whereby a request would never be signed when the target Secret was not created or was misconfigured before the request.commonLabels
which gives you the capability to add the same label on all the resource deployed by the chart. (#5208, @thib-mary)experimental.cert-manager.io/private-key-secret-name
doesn't exist. (#5323, @JoshVanL)accessKeyID
or secretAccessKeyID
. (#5339, @JoshVanL)cmctl
and kubectl cert-manager
now report their actual versions instead of "canary", fixing issue #5020 (#5022, @maelvls)1.19
(#5466, @lucacome).bazel
and .bzl
files from cert-manager now that bazel has been fully replaced (#5340, @SgtCoDFish)v0.25.2
. (#5456, @lucacome)cert-manager
being the container name. (#5410, @rgl)Thank you to the following community members who had a merged PR for this version - your contributions are at the heart of everything we do!
Thanks also to the following maintainers who worked on cert-manager 1.10:
Published by jetstack-release-bot about 2 years ago
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
Version 1.10 adds a variety of quality-of-life fixes and features including improvements to the test suite.
issuer_name
, issuer_kind
and issuer_group
labels to certificate_expiration_timestamp_seconds
, certmanager_certificate_renewal_timestamp_seconds
and certmanager_certificate_ready_status
metrics (#5461, @dkulchinsky)cert-manager.io/private-key-secret-name
. This resolves an issue whereby a request would never be signed when the target Secret was not created or was misconfigured before the request. (#5336, @JoshVanL)experimental.cert-manager.io/private-key-secret-name
. This resolves an issue whereby a request would never be signed when the target Secret was not created or was misconfigured before the request.commonLabels
which gives you the capability to add the same label on all the resource deployed by the chart. (#5208, @thib-mary)experimental.cert-manager.io/private-key-secret-name
doesn't exist. (#5323, @JoshVanL)accessKeyID
or secretAccessKeyID
. (#5339, @JoshVanL)cmctl
and kubectl cert-manager
now report their actual versions instead of "canary", fixing issue #5020 (#5022, @maelvls)1.19
(#5466, @lucacome).bazel
and .bzl
files from cert-manager now that bazel has been fully replaced (#5340, @SgtCoDFish)v0.25.2
. (#5456, @lucacome)cert-manager
being the container name. (#5410, @rgl)Thank you to the following community members who had a merged PR for this version - your contributions are at the heart of everything we do!
Thanks also to the following maintainers who worked on cert-manager 1.10:
Published by jetstack-release-bot about 2 years ago
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
Version 1.9.1 is a bugfix release which removes an incorrect check in the Route53 DNS solver. This accidental change prevented the use of credentials derived from instance metadata or AWS pod metadata.
Thanks to @danquack and @ArchiFleKs for raising this issue, and @danquack and @JoshVanL for fixing it!
accessKeyID
or secretAccessKeyID
. (#5341, @JoshVanL @danquack )Published by jetstack-release-bot about 2 years ago
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
The new version adds alpha support for using cert-manager Certificate
s in scenarios where the ordering of the Relative Distinguished Names (RDN) sequence that constitutes an X.509 certificate's subject needs to be preserved; improves the ability to configure the Certificate
created via ingress-shim using annotations on the Ingress
resource; introduces various changes/improvements in contributor flow; and finishes the new make-based contributor workflow.
cert-manager's Certificate
allows users to configure the subject fields of the X.509 certificate via spec.subject
and spec.commonName
fields. The X.509 spec states that the subject is an (ordered) sequence of Relative Distinguished Names (RDN).
cert-manager does not strictly abide by this spec when encoding the subject fields from the Certificate
spec. For example, the order of the RDN sequence may not be preserved. This is because cert-manager uses Go's libraries for X.509 certificates, and the Go libraries don't preserve ordering.
For the vast majority of users this does not matter, but there are specific cases that require defining the exact ordered RDN sequence. For example, if the certificate is used for LDAP authentication and the RDN sequence represents a location in LDAP directory tree. See cert-manager#3203
.
For these use cases, a new alpha LiteralSubject
field has been added to the Certificate
spec where users can pass a literal RDN sequence:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: test
spec:
secretName: test
literalSubject: "C=US,O=myOrg,CN=someName"
To use this field, the alpha feature gate LiteralCertificateSubject
needs to be enabled on both the cert-manager controller and webhook. Bear in mind that spec.literalSubject
is mutually exclusive with spec.commonName
and spec.subject
.
This feature is aimed at the specific scenario where an exact RDN sequence needs to be defined. We do not intend to deprecate the existing spec.subject
and spec.commonName
fields and we recommend that folks keep using those fields in all other cases; they're simpler, have better validation and are more obvious to read and change.
Certificate
Configurationcert-manager 1.9 adds the ability to configure an ingress-shim Certificate
's spec.revisionHistoryLimit
and spec.privateKey
via annotations on the Ingress
resource.
This should allow folks to configure ingress-shim Certificate
s according to best practices (i.e by setting Certificate
's spec.privateKey.rotationPolicy
to Always
).
In the future we would like to design a better mechanism to configure these Certificate
s. We advise caution when using Ingress
annotations as there is no validation of the annotations at Ingress
creation time.
Over the past couple of months there have been a number of discussions in regards to contributor experience and project health, partially triggered by the awesome community discussions in cert-manager's KubeCon booth and also by the work done to move cert-manager to CNCF's incubating stage.
For example, we've clarified our feature policy and discussed the process of building cert-manager's roadmap. If you're interested in these topics, we're happy to chat about them!
make
Workflowcert-manager 1.8 introduced a new make
based workflow alongside the existing Bazel workflow. The work to improve the make
workflow was continued in 1.9 and our contributor documentation has been redefined to use make
commands. This should make building and testing cert-manager easier with faster build and test times, easier debugging and less complexity.
As part of this, Bazel has now been fully deprecated for building and testing cert-manager.
As usual, we welcome any feedback in regards to further improving contributor experience.
Thank you to the following community members who had a merged PR for this version - your contributions are at the heart of everything we do!
Thanks also to the following maintainers who worked on cert-manager 1.9:
make clean-all
for starting a fresh development environment and make which-go
for getting go version information when developing cert-manager (#5118, @SgtCoDFish)make upload-release
target for publishing cert-manager releases to GCS, simplifying the cert-manager release process simpler and making it easier to change (#5205, @SgtCoDFish)certmanager_http_venafi_client_request_duration_seconds
which allows tracking the latency of Venafi API calls. The metric is labelled by the type of API call. Example PromQL query: certmanager_http_venafi_client_request_duration_seconds{api_call="request_certificate"}
will show the average latency of calls to the Venafi certificate request endpoint (#5053, @irbekrm)cert-manager.io/revision-history-limit
annotation for Ingress resources, to limit the number of CertificateRequests which are kept for a Certificate (#5221, @oGi4i)literalSubject
field for Certificate resources. This is an alpha feature, enabled by passing the flag --feature-gates=LiteralCertificateSubject=true
to the cert-manager controller and webhook. literalSubject
allows fine-grained control of the subject a certificate should have when issued and is intended for power-users with specific use cases in mind (#5002, @spockz)bin
to _bin
, which plays better with certain tools which might treat bin
as just another source directory (#5130, @SgtCoDFish)namespace
parameter which allows users to override the namespace in which resources will be created. This also allows users to set the namespace of the chart when using cert-manager as a sub chart. (#5141, @andrewgkew)curl
, to reduce flakes in tests and development environments (#5272, @SgtCoDFish)make release-artifacts
only builds unsigned artifacts as intended (#5181, @SgtCoDFish)./
is stripped from paths. This ensures that behaviour is the same as v1.7 and earlier (#5050, @jahrlin)cmctl
and kubectl cert-manager
now report their actual versions instead of "canary", fixing issue #5020 (#5286, @jetstack-bot)make update-all
as a convenience target to run before raising a PR (#5251, @SgtCoDFish)experimental.cert-manager.io/private-key-secret-name
doesn't exist. (#5332, @jetstack-bot)securityContext.enabled
from helm chart (#4721, @Dean-Coakley)v0.24.2
. (#5097, @lucacome)Published by jetstack-release-bot over 2 years ago
curl
, to reduce flakes in tests and development environments (#5272, @SgtCoDFish)Published by jetstack-release-bot over 2 years ago
make update-all
as a convenience target to run before raising a PR (#5251, @SgtCoDFish)v0.24.2
. (#5097, @lucacome)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.9 adds a variety of quality-of-life fixes and features including more improvements to the build and release process,
the ability to more precisely control how X.509 Certificate subjects are formatted for power users and a slew of other changes.
Thank you to the following community members who had a merged PR for this version - your contributions are at the heart of everything we do!
Thanks also to the following maintainers who worked on cert-manager 1.9:
make clean-all
for starting a fresh development environment and make which-go
for getting go version information when developing cert-manager (#5118, @SgtCoDFish)make upload-release
target for publishing cert-manager releases to GCS, simplifying the cert-manager release process simpler and making it easier to change (#5205, @SgtCoDFish)certmanager_http_venafi_client_request_duration_seconds
which allows tracking the latency of Venafi API calls. The metric is labelled by the type of API call. Example PromQL query: certmanager_http_venafi_client_request_duration_seconds{api_call="request_certificate"}
will show the average latency of calls to the Venafi certificate request endpoint (#5053, @irbekrm)cert-manager.io/revision-history-limit
annotation for Ingress resources, to limit the number of CertificateRequests which are kept for a Certificate (#5221, @oGi4i)literalSubject
field for Certificate resources. This is an alpha feature, enabled by passing the flag --feature-gates=LiteralCertificateSubject=true
to the cert-manager controller and webhook. literalSubject
allows fine-grained control of the subject a certificate should have when issued and is intended for power-users with specific use cases in mind (#5002, @spockz)bin
to _bin
, which plays better with certain tools which might treat bin
as just another source directory (#5130, @SgtCoDFish)namespace
parameter which allows users to override the namespace in which resources will be created. This also allows users to set the namespace of the chart when using cert-manager as a sub chart. (#5141, @andrewgkew)make release-artifacts
only builds unsigned artifacts as intended (#5181, @SgtCoDFish)./
is stripped from paths. This ensures that behaviour is the same as v1.7 and earlier (#5050, @jahrlin)Published by jetstack-release-bot over 2 years ago
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
v1.7.3 is in effect a bug fix release which increases some hard-coded timeouts which were preventing the use of certain ACME issuers
which sometimes had slower response times. This is known to include ZeroSSL and Sectigo.
These issues were reported by many users. We'd like to thank the following for their help and feedback on this topic:
Thanks also to the cert-manager maintainers who were involved in reviewing this fix and helping to move things forwards:
Published by jetstack-release-bot over 2 years ago
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
v1.8.2 is in effect a bug fix release which increases some hard-coded timeouts which were preventing the use of certain ACME issuers
which sometimes had slower response times. This is known to include ZeroSSL and Sectigo.
These issues were reported by many different users and We'd like to thank the following for their help, suggestions and feedback on this topic:
Thanks also to the cert-manager maintainers who were involved in reviewing this fix and helping to move things forwards:
Published by jetstack-release-bot over 2 years ago
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
1.8.1 is a patch release rebuilding cert-manager 1.8 using the latest version of Go.
Reverts a check for Prometheus APIs before creating cert-manager ServiceMonitors which broke users' GitOps flows (cert-manager#5204)
Bumps the version of Go used to build the cert-manager binaries to 1.17.11 which fixes a few CVEs (we don't think that those were likely to be exploited in cert-manager) (cert-manager#5203, @irbekrm )
Published by jetstack-release-bot over 2 years ago
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
cert-manager 1.8 includes wider support for Kubernetes server-side-apply, a new build and development experience based around
Makefile
s rather than Bazel, and a range of other improvements, tweaks and bug fixes.
Version 1.8 also marks our first release in which the Go import path for cert-manager is that of the repo's new home:
github.com/cert-manager/cert-manager
rotationPolicy
fieldThe field spec.privateKey.rotationPolicy
on Certificate resources is now validated. Valid options are Never and Always. If you are using a GitOps flow and one of your YAML manifests contains a Certificate with an invalid value, you will need to update it with a valid value to prevent your GitOps tool from failing on the new validation. Please follow the instructions listed on the page Upgrading from v1.7 to v1.8. (#4913, @jahrlin)
After upgrading to 1.8.0, when updating existing Certificate objects that have an incorrect value for rotationPolicy
, Kubernetes clients such as kubectl, Helm, or ArgoCD will start showing the following message:
Certificate.cert-manager.io "my-cert" is invalid: spec.privateKey.rotationPolicy: Unsupported value: "Foo": supported values: "Never", "Always".
Previously, when the value of the rotationPolicy
field was set to an incorrect value, you would not know since no event or condition would be visible on the Certificate itself. The only way to know that something was wrong was to dig into the cert-manager-controller logs and see the message "Certificate with unknown certificate.spec.privateKey.rotationPolicy
value":
I0329 12:43:13.325771 1 keymanager_controller.go:176] cert-manager/certificates-key-manager "msg"="Certificate with unknown certificate.spec.privateKey.rotationPolicy value" "key"="default/my-cert" "rotation_policy"="Foo"
This change was implemented in #4913.
This only affects you if you're modifying cert-manager containers in some way, such as adding init scripts or otherwise
changing how the binaries inside the containers are called.
Bazel has a unique way of creating containers, which places the actual binary at a long unusual path. For the v1.7.0 cert-manager-webhook
container for example, the binary is placed at /app/cmd/webhook/webhook.runfiles/com_github_jetstack_cert_manager/cmd/webhook/webhook_/webhook
and /app/cmd/webhook/webhook
is provided as a symlink to the binary.
This is simplified in our new build system; we only place a single binary at /app/cmd/webhook/webhook
and the old path disappears.
This applies to all cert-manager containers.
We also removed the "LICENSES" file from the containers and replaced it with a link to the cert-manager repo.
.exe
Extension on WindowsWe package cmctl
and kubectl_cert-manager
for Windows on amd64
platforms, but previously the binaries had the
same names as the binaries on other platforms, e.g. cmctl
with no file extension.
In 1.8.0 and later, the binaries now have a .exe
extension since this is standard practice on Windows. This could affect you
if you're calling the binary in a Powershell script, for example.
We've also now added zip-compressed versions of the cmctl
and kubectl_cert-manager
binaries on Windows, since .tar.gz
is less
common on Windows.
This will only affect you if you're writing code in Go which imports cert-manager as a module, which we generally recommend against
doing in most cases.
All versions of cert-manager prior to v1.8.0 used a Go import path corresponding to the old cert-manager repository, github.com/jetstack/cert-manager
.
v1.8.0 marks the first release in which the import path changes to the new location, github.com/cert-manager/cert-manager
.
We have a guide for Importing cert-manager in Go on cert-manager.io with all the details, including
details on why we don't recommend importing cert-manager as a module if that's avoidable.
cert-manager v1.8.0 adds initial support for Kubernetes Server-Side Apply, which became stable
in Kubernetes 1.22. This support is behind a feature gate for now, and is only supported by cert-manager on Kubernetes 1.22 and later.
Server-Side Apply helps to ensure that changes to resources are made in a managed way, and aims to prevent certain classes of bugs. Notably, it should
eliminate conflicts when multiple controllers try to apply status changes to a single resource. You'll likely have seen messages relating to this kind of
conflict in logs before, e.g.:
I0119 12:34:56.000000 1 controller.go:161] cert-manager/controller/certificaterequests-issuer-acme "msg"="re-queuing item due to optimistic locking on resource" "key"="my-namespace/my-cr" "error"="Operation cannot be fulfilled on certificaterequests.cert-manager.io \"my-cr\": the object has been modified; please apply your changes to the latest version and try again"
These conflicts aren't usually actually a problem which will block the issuance of a certificate, but they can delay things as they cause extra
reconcile loops. Server-side apply cleans things up, which should mean less noise in logs and fewer pointless reconcile loops.
If you want to test it out, you can enable alpha-level cert-manager Server-Side Apply support through the
--feature-gates
controller flag.
A common theme when someone tries to make a change to cert-manager for the first time is that they ask for help with navigating Bazel, which cert-manager
used as its build tool. Helping people with Bazel isn't easy; it's an incredibly powerful tool, but that power also brings a lot of complications
which can seriously get in the way of being able to make even simple changes to the code base. Even developers who are familiar with contributing
to open source projects in Go can find it daunting to make changes thanks to Bazel.
The problem isn't limited to open-source contributors; many of cert-manager's maintainers also struggle with configuring and changing Bazel, too.
cert-manager 1.8 is the first release which is built and tested using a newly written make
-based build system. We believe that this new build system should
make it much simpler to understand and change the commands which are being run behind the scenes to build and test cert-manager. In time, we'll fully
document the new build system, ensure it's at full feature-parity with Bazel and then remove all references to Bazel across the codebase.
A neat side effect of this change is that our build times have significantly improved. Bazel took around 14 minutes to build every cert-manager
artifact for every platform during a release, while the new make
build system can do the same (and more) in under 5 minutes.
cert-manager v1.8.0 introduces exponential backoff after failed certificate issuance.
Previously, a failed issuance was retried every hour which — especially in larger cert-manager installations — could cause rate limits to be hit as well as overwhelm external services. Failed attempts
are now retried with a binary exponential backoff starting with 1h
then 2h
, 4h
up to a maximum of 32h
. As part of the new backoff behavior, a new failedIssuanceAttempts
field was added to the
Certificate
spec to track the number of currently failed issuances.
The cmctl renew
command command can still be used to force Certificate
renewal immediately.
We're also considering reducing the initial backoff from 1 hour. If you have a use case where this would be useful please do comment on our tracking issue.
cert-manager thrives thanks to the community and we're always grateful for receiving open-source contributions!
Thanks to the following community members who landed a commit in this release:
Thanks also to the cert-manager maintainer team involved with this release
spec.privateKey.rotationPolicy
on Certificate resources is now validated. Valid options are Never and Always. If you are using a GitOps flow and one of your YAML manifests contains a Certificate with an invalid value, you will need to update it with a valid value to prevent your GitOps tool from failing on the new validation. (#4913, @jahrlin)spec.expirationSeconds
on Kubernetes CertificateSigningRequest resources. Using this field requires Kubernetes 1.22. You can still use the annotation experimental.cert-manager.io/request-duration
to request a duration. (#4957, @enj)tls-combined.pem
and key.der
on Secret resources that are associated to Certificate resources that use the field additionalOutputFormats
. The field additionalOutputFormat
is an alpha feature and can be enabled by passing the flag --feature-gates=AdditionalCertificateOutputFormats=true
to the cert-manager controller. (#4813, @JoshVanL)ServerSideApply=true
now configures the ingress-shim
and gateway-shim
controllers to use Kubernetes Server-Side Apply on Certificate resources. When upgrading to cert-manger 1.8 with ServerSideApply=true
, do make sure there are no Challenge resources currently in the cluster. If there are some, you will need to manually delete them once they are in 'valid' state as cert-manager post-1.8 with the Server-Side Apply feature is not able to clean up Challenge resources created pre-1.8. (#4811, @JoshVanL)ServerSideApply=true
configures the certificaterequests-*
controllers to use Kubernetes Server-Side Apply on CertificateRequest resources. (#4792, @JoshVanL)ServerSideApply=true
configures the certificates-*
controllers to use Kubernetes Server-Side Apply on Certificate resources. (#4777, @JoshVanL)ServerSideApply=true
configures the CertificateSigningRequest controllers to use Kubernetes Server-Side Apply on CertificateSigningRequest resources. (#4798, @JoshVanL)ServerSideApply=true
configures the issuers
and clusterissuers
controllers to use Kubernetes Server-Side Apply on Issuer and ClusterIssuer resources. (#4794, @JoshVanL)ServerSideApply=true
configures the orders
controller to use Kubernetes Server-Side Apply on Order resources. (#4799, @JoshVanL)experimental.cert-manager.io/request-duration
now has a minimum value of 600 seconds. This annotation This change ensures compatibility with the Kubernetes resource CertificateSigningRequest, which requires a minimum of 600 seconds on the field spec.expirationSeconds
. (#4973, @irbekrm)ingress.kubernetes.io/whitelist-source-range
used by the Ingress shim when creating Ingress resources can now be overridden by setting the field ingressTemplate
on the Issuer and ClusterIssuer. (#4789, @tasharnvb)cert-manager-<component name>/<version> (<os>/<arch>) cert-manager/<git commit>
. Another change is the addition of specific field managers strings; previously, all the controllers had the same field manager cert-manager
. Now, each controller has its own field manager string of the form cert-manager-<controller name>
. (#4773, @JoshVanL)cmctl experimental uninstall
. (#4897, @jahrlin)--default-issuer-group
, --default-issuer-kind
, and --default-issuer-name
. (#4833, @jakexks)github.com/cert-manager/cert-manager
. If you import cert-manager as a go module (which isn't currently recommended), you'll need to update the module import path in your code to import cert-manager 1.8 or later. (#4587, @SgtCoDFish)additionalOutputFormats
, which is available as an alpha feature on Certificate resources, is now correctly validated. Previously, it would only get validated when the privateKey
field was set on the Certificate. If you are using the additionalOutputFormats
field, you will want to add the feature gate AdditionalCertificateOutputFormats
to both the webhook and the controller. Previously, you only needed to set AdditionalCertificateOutputFormats
on the controller. If the feature gate is missing on either the controller or the webhook, you won't be able to use the additionalOutputFormat
field. (#4814, @JoshVanL)kubernetes.io/os: linux
. If this label isn't present on any nodes in the cluster, the nodeSelector
will need to be overwritten, or that label added to some nodes. (#3605, @mikebryant)cmctl renew
command in their namespaces. (#4955, @andreadecorte)1h
, 2h
, 4h
, 8h
, 16h
, 32h
. A new field failedIssuanceAttempts
is now set by cert-manager on the Certificate status. This field keeps track of consecutive failed issuances. The backoff period gets reset after a successful issuance. Like before, updating a field on a failed Certificate (such as spec.dnsNames
) or running the command cmctl renew
continues to trigger a re-issuance. (#4772, @irbekrm)serviceAccount.labels
, cainjector.serviceAccount.labels
, webhook.serviceAccount.labels
, and startupapicheck.serviceAccount.labels
. (#4932, @4molybdenum2)controller_sync_error_count
counting the number of errors during sync() of a controller. (#4987, @jayme-github)allowPrivilegeEscalation
to false
by default. The Helm chart now also sets securityContext.allowPrivilegeEscalation
to false
by default for the controller, cainjector, and webhook pods as well as for the startupapicheck job. (#4953, @ajvn)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.8 includes wider support for Kubernetes server-side-apply, a new build and development experience based around
Makefile
s rather than Bazel, and a range of other improvements, tweaks and bug fixes.
v1.8 also marks our first release in which the Golang import path for cert-manager is that of the repo's new home:
github.com/cert-manager/cert-manager
This only affects you if you're modifying cert-manager containers in some way, such as adding init scripts or otherwise
changing how the binaries inside the containers are called.
Bazel has a unique way of creating containers, which places the actual binary at a long, unusual path. For the v1.7.0 cert-manager-webhook
container for example, the binary is placed at /app/cmd/webhook/webhook.runfiles/com_github_jetstack_cert_manager/cmd/webhook/webhook_/webhook
and /app/cmd/webhook/webhook
is provided as a symlink to the binary.
This is simplified in our new build system; we only place a single binary at /app/cmd/webhook/webhook
and the old path disappears.
This applies to all cert-manager containers.
We also removed the "LICENSES" file from the containers and replaced it with a link to the cert-manager repo; this reduces container sizes since the LICENSES file was surprisingly large.
.exe
Extension on WindowsWe package cmctl
and kubectl_cert-manager
for Windows on amd64
platforms, but previously the binaries had the
same names as the binaries on other platforms, e.g. cmctl
with no file extension.
In 1.8.0 and later, the binaries now have a .exe
extension since this is standard practice on Windows. This could affect you
if you're calling the binary in a Powershell script, for example.
We've also now added zip-compressed versions of the cmctl
and kubectl_cert-manager
binaries on Windows, since .tar.gz
is less
common on that platform.
This will only affect you if you're writing code in Go which imports cert-manager as a module, which we generally recommend against
doing in most cases.
All versions of cert-manager prior to v1.8.0 used a Go import path corresponding to the old cert-manager repository, github.com/jetstack/cert-manager
.
v1.8.0 marks the first release in which the import path changes to the new location, github.com/cert-manager/cert-manager
.
We have a guide for Importing cert-manager in Go on cert-manager.io with all the information you'll need, including details on why we don't recommend importing cert-manager as a module if at all possible.
cert-manager thrives thanks to the community and we're always grateful for receiving contributions from open-source community members!
Thanks to the following community members who landed a commit in this release:
Thanks also to the cert-manager maintainer team involved with this release
--feature-gates=AdditionalCertificateOutputFormats=true
flag. (#4813, @JoshVanL)cert-manager<component name>/<version> (<os>/<arch>) cert-manager/<git commit>
. Field managers now take the form of cert-manager<component name>
. (#4773, @JoshVanL)ServerSideApply=true
configures the certificate-shim controllers to use Kubernetes Server Side Apply on Certificate resources. (#4811, @JoshVanL)ServerSideApply=true
configures the order controller to use Kubernetes Server Side Apply on Order resources. (#4799, @JoshVanL)ServerSideApply=true
configures the certificaterequest controllers to use Kubernetes Server Side Apply on CertificateRequest resources. (#4792, @JoshVanL)ServerSideApply=true
configures the certificates controllers to use Kubernetes Server Side Apply on Certificate resources. (#4777, @JoshVanL)ServerSideApply=true
configures the certificatesigningrequest controllers to use Kubernetes Server Side Apply on CertificateRequest resources. (#4798, @JoshVanL)ServerSideApply=true
configures the issuer and clusterissuer controllers to use Kubernetes Server Side Apply on CertificateRequest resources. (#4794, @JoshVanL)cmctl experimental uninstall
. (#4897, @jahrlin)--enable-certificate-owner-ref
controller flag. (#4888, @JoshVanL)labels
on the gatewayHTTPRoute solver is now optional. (#4967, @maelvls)ServerSideApply=true
configures the challenges controller to use Kubernetes Server Side Apply on Challenge resources.ServerSideApply=true
, do make sure there are no Challenge
resources currently in the cluster. If there are some, you will need to manually delete them once they are in 'valid' state as cert-manager post-v1.8 with the SSA feature is not able to clean up Challenge
CRs created pre-v1.8. (#4808, @JoshVanL)certificate.spec.privateKey.rotationPolicy
. Valid options are Never
and Always
. Existing Certificate resources with incorrect values needs to be updated. (#4898 (#4913, @jahrlin)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. The 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. (#4814, @JoshVanL)kubernetes.io/os: linux
. If this label isn't present on any nodes in the cluster, the nodeSelector
will need to be overwritten, or that label added to some Nodes. (#3605, @mikebryant)failedIssuanceAttempts
is added to Certificate
's status that keeps track of consecutive failed issuances. Backoff period gets reset by a successful issuance. The current behaviour where changing certain fields on Certificate
s spec (such as DNS names) or manually renewing using cmctl
tool remains unchanged. (#4772, @irbekrm)serviceAccount
labels in helm charts (#4932, @4molybdenum2)allowPrivilegeEscalation
in container security context to false
by default when not set for acmesolver pod, and set allowPrivilegeEscalation
to false
by default for controller, cainjector, webhook pods and the startupapicheck job (#4953, @ajvn)controller_sync_error_count
counting the number of errors during sync() of a controller. (#4987, @jayme-github)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.8 includes wider support for Kubernetes server-side-apply, a new build and development experience based around
Makefile
s rather than Bazel, and a range of other improvements, tweaks and bug fixes.
v1.8 also marks our first release in which the Golang import path for cert-manager is that of the repo's new home:
github.com/cert-manager/cert-manager
This only affects you if you're modifying cert-manager containers in some way, such as adding init scripts or otherwise
changing how the binaries inside the containers are called.
Bazel has a unique way of creating containers, which places the actual binary at a long, unusual path. For the v1.7.0 cert-manager-webhook
container for example, the binary is placed at /app/cmd/webhook/webhook.runfiles/com_github_jetstack_cert_manager/cmd/webhook/webhook_/webhook
and /app/cmd/webhook/webhook
is provided as a symlink to the binary.
This is simplified in our new build system; we only place a single binary at /app/cmd/webhook/webhook
and the old path disappears.
This applies to all cert-manager containers.
We also removed the "LICENSES" file from the containers and replaced it with a link to the cert-manager repo; this reduces container sizes since the LICENSES file was surprisingly large.
.exe
Extension on WindowsWe package cmctl
and kubectl_cert-manager
for Windows on amd64
platforms, but previously the binaries had the
same names as the binaries on other platforms, e.g. cmctl
with no file extension.
In 1.8.0 and later, the binaries now have a .exe
extension since this is standard practice on Windows. This could affect you
if you're calling the binary in a Powershell script, for example.
We've also now added zip-compressed versions of the cmctl
and kubectl_cert-manager
binaries on Windows, since .tar.gz
is less
common on that platform.
This will only affect you if you're writing code in Go which imports cert-manager as a module, which we generally recommend against
doing in most cases.
All versions of cert-manager prior to v1.8.0 used a Go import path corresponding to the old cert-manager repository, github.com/jetstack/cert-manager
.
v1.8.0 marks the first release in which the import path changes to the new location, github.com/cert-manager/cert-manager
.
We have a guide for Importing cert-manager in Go on cert-manager.io with all the information you'll need, including details on why we don't recommend importing cert-manager as a module if at all possible.
cert-manager thrives thanks to the community and we're always grateful for receiving contributions from open-source community members!
Thanks to the following community members who landed a commit in this release:
Thanks also to the cert-manager maintainer team involved with this release
--feature-gates=AdditionalCertificateOutputFormats=true
flag. (#4813, @JoshVanL)cert-manager<component name>/<version> (<os>/<arch>) cert-manager/<git commit>
. Field managers now take the form of cert-manager<component name>
. (#4773, @JoshVanL)ServerSideApply=true
configures the certificate-shim controllers to use Kubernetes Server Side Apply on Certificate resources. (#4811, @JoshVanL)ServerSideApply=true
configures the order controller to use Kubernetes Server Side Apply on Order resources. (#4799, @JoshVanL)ServerSideApply=true
configures the certificaterequest controllers to use Kubernetes Server Side Apply on CertificateRequest resources. (#4792, @JoshVanL)ServerSideApply=true
configures the certificates controllers to use Kubernetes Server Side Apply on Certificate resources. (#4777, @JoshVanL)ServerSideApply=true
configures the certificatesigningrequest controllers to use Kubernetes Server Side Apply on CertificateRequest resources. (#4798, @JoshVanL)ServerSideApply=true
configures the issuer and clusterissuer controllers to use Kubernetes Server Side Apply on CertificateRequest resources. (#4794, @JoshVanL)cmctl experimental uninstall
. (#4897, @jahrlin)--enable-certificate-owner-ref
controller flag. (#4888, @JoshVanL)labels
on the gatewayHTTPRoute solver is now optional. (#4967, @maelvls)certificate.spec.privateKey.rotationPolicy
. Valid options are Never
and Always
. Existing Certificate resources with incorrect values needs to be updated. (#4898 (#4913, @jahrlin)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. The 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. (#4814, @JoshVanL)kubernetes.io/os: linux
. If this label isn't present on any nodes in the cluster, the nodeSelector
will need to be overwritten, or that label added to some Nodes. (#3605, @mikebryant)failedIssuanceAttempts
is added to Certificate
's status that keeps track of consecutive failed issuances. Backoff period gets reset by a successful issuance. The current behaviour where changing certain fields on Certificate
s spec (such as DNS names) or manually renewing using cmctl
tool remains unchanged. (#4772, @irbekrm)serviceAccount
labels in helm charts (#4932, @4molybdenum2)allowPrivilegeEscalation
in container security context to false
by default when not set for acmesolver pod, and set allowPrivilegeEscalation
to false
by default for controller, cainjector, webhook pods and the startupapicheck job (#4953, @ajvn)controller_sync_error_count
counting the number of errors during sync() of a controller. (#4987, @jayme-github)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.8 includes wider support for Kubernetes server-side-apply, a new build and development experience based around
Makefile
s rather than Bazel, and a range of other improvements, tweaks and bug fixes.
v1.8 also marks our first release in which the Golang import path for cert-manager is that of the repo's new home:
github.com/cert-manager/cert-manager
⚠️ This section does not apply for cert-manager v1.8.0-alpha.1
This only affects you if you're modifying cert-manager containers in some way, such as adding init scripts or otherwise
changing how the binaries inside the containers are called.
Bazel has a unique way of creating containers, which places the actual binary at a long unusual path. For the v1.7.0 cert-manager-webhook
container for example, the binary is placed at /app/cmd/webhook/webhook.runfiles/com_github_jetstack_cert_manager/cmd/webhook/webhook_/webhook
and /app/cmd/webhook/webhook
is provided as a symlink to the binary.
This is simplified in our new build system; we only place a single binary at /app/cmd/webhook/webhook
and the old path disappears.
This applies to all cert-manager containers.
We also removed the "LICENSES" file from the containers and replaced it with a link to the cert-manager repo.
.exe
Extension on Windows⚠️ This section does not apply for cert-manager v1.8.0-alpha.1
We package cmctl
and kubectl_cert-manager
for Windows on amd64
platforms, but previously the binaries had the
same names as the binaries on other platforms, e.g. cmctl
with no file extension.
In 1.8.0 and later, the binaries now have a .exe
extension since this is standard practice on Windows. This could affect you
if you're calling the binary in a Powershell script, for example.
We've also now added zip-compressed versions of the cmctl
and kubectl_cert-manager
binaries on Windows, since .tar.gz
is less
common on that platform.
This will only affect you if you're writing code in Go which imports cert-manager as a module, which we generally recommend against
doing in most cases.
All versions of cert-manager prior to v1.8.0 used a Go import path corresponding to the old cert-manager repository, github.com/jetstack/cert-manager
.
v1.8.0 marks the first release in which the import path changes to the new location, github.com/cert-manager/cert-manager
.
We have a guide for Importing cert-manager in Go on cert-manager.io with all the details, including
details on why we don't recommend importing cert-manager as a module if that's avoidable.
cert-manager thrives thanks to the community and we're always grateful for receiving contributions from open-source community members!
Thanks to the following community members who landed a commit in this release:
Thanks also to the cert-manager maintainer team involved with this release
--feature-gates=AdditionalCertificateOutputFormats=true
flag. (#4813, @JoshVanL)cert-manager<component name>/<version> (<os>/<arch>) cert-manager/<git commit>
. Field managers now take the form of cert-manager<component name>
. (#4773, @JoshVanL)ServerSideApply=true
configures the certificate-shim controllers to use Kubernetes Server Side Apply on Certificate resources. (#4811, @JoshVanL)ServerSideApply=true
configures the order controller to use Kubernetes Server Side Apply on Order resources. (#4799, @JoshVanL)ServerSideApply=true
configures the certificaterequest controllers to use Kubernetes Server Side Apply on CertificateRequest resources. (#4792, @JoshVanL)ServerSideApply=true
configures the certificates controllers to use Kubernetes Server Side Apply on Certificate resources. (#4777, @JoshVanL)ServerSideApply=true
configures the certificatesigningrequest controllers to use Kubernetes Server Side Apply on CertificateRequest resources. (#4798, @JoshVanL)ServerSideApply=true
configures the issuer and clusterissuer controllers to use Kubernetes Server Side Apply on CertificateRequest resources. (#4794, @JoshVanL)cmctl experimental uninstall
. (#4897, @jahrlin)certificate.spec.privateKey.rotationPolicy
. Valid options are Never
and Always
. Existing Certificate resources with incorrect values needs to be updated. (#4898 (#4913, @jahrlin)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. The 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. (#4814, @JoshVanL)failedIssuanceAttempts
is added to Certificate
's status that keeps track of consecutive failed issuances. Backoff period gets reset by a successful issuance. The current behaviour where changing certain fields on Certificate
s spec (such as DNS names) or manually renewing using cmctl
tool remains unchanged. (#4772, @irbekrm)serviceAccount
labels in helm charts (#4932, @4molybdenum2)allowPrivilegeEscalation
in container security context to false
by default when not set for acmesolver pod, and set allowPrivilegeEscalation
to false
by default for controller, cainjector, webhook pods and the startupapicheck job (#4953, @ajvn)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.8 includes wider support for Kubernetes server-side-apply, a new build and development experience based around
Makefile
s rather than Bazel, and a range of other improvements, tweaks and bug fixes.
v1.8 also marks our first release in which the Golang import path for cert-manager is that of the repo's new home:
github.com/cert-manager/cert-manager
⚠️ This section does not apply for v1.8.0-alpha.0!
This only affects you if you're modifying cert-manager containers in some way, such as adding init scripts or otherwise
changing how the binaries inside the containers are called.
Bazel has a unique way of creating containers, which places the actual binary at a long unusual path. For the v1.7.0 cert-manager-webhook
container for example, the binary is placed at /app/cmd/webhook/webhook.runfiles/com_github_jetstack_cert_manager/cmd/webhook/webhook_/webhook
and /app/cmd/webhook/webhook
is provided as a symlink to the binary.
This is simplified in our new build system; we only place a single binary at /app/cmd/webhook/webhook
and the old path disappears.
This applies to all cert-manager containers.
We also removed the "LICENSES" file from the containers and replaced it with a link to the cert-manager repo.
.exe
Extension on Windows⚠️ This section does not apply for v1.8.0-alpha.0!
We package cmctl
and kubectl_cert-manager
for Windows on amd64
platforms, but previously the binaries had the
same names as the binaries on other platforms, e.g. cmctl
with no file extension.
In 1.8.0 and later, the binaries now have a .exe
extension since this is standard practice on Windows. This could affect you
if you're calling the binary in a Powershell script, for example.
We've also now added zip-compressed versions of the cmctl
and kubectl_cert-manager
binaries on Windows, since .tar.gz
is less
common on that platform.
This will only affect you if you're writing code in Go which imports cert-manager as a module, which we generally recommend against
doing in most cases.
All versions of cert-manager prior to v1.8.0 used a Go import path corresponding to the old cert-manager repository, github.com/jetstack/cert-manager
.
v1.8.0 marks the first release in which the import path changes to the new location, github.com/cert-manager/cert-manager
.
We have a guide for Importing cert-manager in Go on cert-manager.io with all the details, including
details on why we don't recommend importing cert-manager as a module if that's avoidable.
cert-manager thrives thanks to the community and we're always grateful for receiving contributions from open-source community members!
Thanks to the following community members who landed a commit in this release:
Thanks also to the cert-manager maintainer team involved with this release
--feature-gates=AdditionalCertificateOutputFormats=true
flag. (#4813, @JoshVanL)cert-manager<component name>/<version> (<os>/<arch>) cert-manager/<git commit>
. Field managers now take the form of cert-manager<component name>
. (#4773, @JoshVanL)ServerSideApply=true
configures the certificaterequest controllers to use Kubernetes Server Side Apply on CertificateRequest resources. (#4792, @JoshVanL)ServerSideApply=true
configures the certificates controllers to use Kubernetes Server Side Apply on Certificate resources. (#4777, @JoshVanL)ServerSideApply=true
configures the certificatesigningrequest controllers to use Kubernetes Server Side Apply on CertificateRequest resources. (#4798, @JoshVanL)ServerSideApply=true
configures the issuer and clusterissuer controllers to use Kubernetes Server Side Apply on CertificateRequest resources. (#4794, @JoshVanL)cmctl experimental uninstall
. (#4897, @jahrlin)certificate.spec.privateKey.rotationPolicy
. Valid options are Never
and Always
. Existing Certificate resources with incorrect values needs to be updated. (#4898 (#4913, @jahrlin)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. The 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. (#4814, @JoshVanL)failedIssuanceAttempts
is added to Certificate
's status that keeps track of consecutive failed issuances. Backoff period gets reset by a successful issuance. The current behaviour where changing certain fields on Certificate
s spec (such as DNS names) or manually renewing using cmctl
tool remains unchanged. (#4772, @irbekrm)serviceAccount
labels in helm charts (#4932, @4molybdenum2)allowPrivilegeEscalation
in container security context to false
by default when not set for acmesolver pod, and set allowPrivilegeEscalation
to false
by default for controller, cainjector, webhook pods and the startupapicheck job (#4953, @ajvn)Published by jetstack-release-bot over 2 years ago
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
1.7.2 is a minor release rebuilding cert-manager 1.7 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.