cert-manager/cert-manager
### [`v1.9.1`](https://togithub.com/cert-manager/cert-manager/releases/tag/v1.9.1)
[Compare Source](https://togithub.com/cert-manager/cert-manager/compare/v1.9.0...v1.9.1)
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](https://togithub.com/danquack) and [@ArchiFleKs](https://togithub.com/ArchiFleKs) for raising this issue, and [@danquack](https://togithub.com/danquack) and [@JoshVanL](https://togithub.com/JoshVanL) for fixing it!
##### Changes since v1.9.0
##### Bug
- DNS Route53: Remove incorrect validation which rejects solvers that don't define either a `accessKeyID` or `secretAccessKeyID`. ([#5341](https://togithub.com/cert-manager/cert-manager/pull/5341), [@JoshVanL](https://togithub.com/JoshVanL) [@danquack](https://togithub.com/danquack) )
### [`v1.9.0`](https://togithub.com/cert-manager/cert-manager/releases/tag/v1.9.0)
[Compare Source](https://togithub.com/cert-manager/cert-manager/compare/v1.8.2...v1.9.0)
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.
#### Major Themes
##### Literal Certificate Subjects
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](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.6) 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](https://ldapwiki.com/wiki/Directory%20Information%20Tree). See [`cert-manager#3203`](https://togithub.com/cert-manager/cert-manager/issues/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:
```yaml
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.
##### ingress-shim `Certificate` Configuration
cert-manager 1.9 adds the ability to configure an ingress-shim `Certificate`'s `spec.revisionHistoryLimit` and `spec.privateKey` via [annotations on the `Ingress` resource](https://cert-manager.io/docs/usage/ingress/#supported-annotations).
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.
##### Contribution Workflow
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](https://cert-manager.io/docs/contributing/policy/) and discussed the process of building cert-manager's [roadmap](https://togithub.com/cert-manager/cert-manager/blob/master/ROADMAP.md). If you're interested in these topics, we're happy to chat about them!
##### `make` Workflow
cert-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](https://cert-manager.io/docs/contributing/building/) 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!
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!
- [@AcidLeroy](https://togithub.com/AcidLeroy)
- [@oGi4i](https://togithub.com/oGi4i)
- [@spockz](https://togithub.com/spockz) (and [@yongk802](https://togithub.com/yongk802) who raised a similar PR)
- [@andrewgkew](https://togithub.com/andrewgkew)
- [@sveba](https://togithub.com/sveba)
- [@rodrigorfk](https://togithub.com/rodrigorfk)
- [@craigminihan](https://togithub.com/craigminihan)
- [@lucacome](https://togithub.com/lucacome)
- [@Dean-Coakley](https://togithub.com/Dean-Coakley)
- [@Compy](https://togithub.com/Compy)
Thanks also to the following maintainers who worked on cert-manager 1.9:
- [@irbekrm](https://togithub.com/irbekrm)
- [@SgtCoDFish](https://togithub.com/SgtCoDFish)
- [@jakexks](https://togithub.com/jakexks)
- [@wallrj](https://togithub.com/wallrj)
- [@maelvls](https://togithub.com/maelvls)
- [@JoshVanL](https://togithub.com/JoshVanL)
- [@jahrlin](https://togithub.com/jahrlin)
- [@munnerz](https://togithub.com/munnerz)
#### Changes since v1.8.0
##### Feature
- Added support for pulling both AWS access key IDs and secret keys from Kubernetes secrets ([#5194](https://togithub.com/cert-manager/cert-manager/issues/5194), [@Compy](https://togithub.com/Compy))
- Adds `make clean-all` for starting a fresh development environment and `make which-go` for getting go version information when developing cert-manager ([#5118](https://togithub.com/cert-manager/cert-manager/issues/5118), [@SgtCoDFish](https://togithub.com/SgtCoDFish))
- Adds `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](https://togithub.com/cert-manager/cert-manager/issues/5205), [@SgtCoDFish](https://togithub.com/SgtCoDFish))
- Adds a new alpha Prometheus summary vector metric `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](https://togithub.com/cert-manager/cert-manager/issues/5053), [@irbekrm](https://togithub.com/irbekrm))
- Adds more verbose logging info for certificate renewal in the DynamicSource webhook to include DNSNames ([#5142](https://togithub.com/cert-manager/cert-manager/issues/5142), [@AcidLeroy](https://togithub.com/AcidLeroy))
- Adds new LICENSES format and ability to verify and update licenses through make ([#5243](https://togithub.com/cert-manager/cert-manager/issues/5243), [@SgtCoDFish](https://togithub.com/SgtCoDFish))
- Adds private key Ingress annotations to set private key properties for Certificate ([#5239](https://togithub.com/cert-manager/cert-manager/issues/5239), [@oGi4i](https://togithub.com/oGi4i))
- Adds the `cert-manager.io/revision-history-limit` annotation for Ingress resources, to limit the number of CertificateRequests which are kept for a Certificate ([#5221](https://togithub.com/cert-manager/cert-manager/issues/5221), [@oGi4i](https://togithub.com/oGi4i))
- Adds the `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](https://togithub.com/cert-manager/cert-manager/issues/5002), [@spockz](https://togithub.com/spockz))
- Change default build dir from `bin` to `_bin`, which plays better with certain tools which might treat `bin` as just another source directory ([#5130](https://togithub.com/cert-manager/cert-manager/issues/5130), [@SgtCoDFish](https://togithub.com/SgtCoDFish))
- Helm: Adds a new `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](https://togithub.com/cert-manager/cert-manager/issues/5141), [@andrewgkew](https://togithub.com/andrewgkew))
- Helm: Allow for users to not auto-mount service account tokens [see also k/k#57601](https://togithub.com/kubernetes/kubernetes/issues/57601) ([#5016](https://togithub.com/cert-manager/cert-manager/issues/5016), [@sveba](https://togithub.com/sveba))
- Use multiple retries when provisioning tools using `curl`, to reduce flakes in tests and development environments ([#5272](https://togithub.com/cert-manager/cert-manager/issues/5272), [@SgtCoDFish](https://togithub.com/SgtCoDFish))
##### Bug or Regression
- CertificateRequests controllers must wait for the core secrets informer to be synced ([#5224](https://togithub.com/cert-manager/cert-manager/issues/5224), [@rodrigorfk](https://togithub.com/rodrigorfk))
- Ensure that `make release-artifacts` only builds unsigned artifacts as intended ([#5181](https://togithub.com/cert-manager/cert-manager/issues/5181), [@SgtCoDFish](https://togithub.com/SgtCoDFish))
- Ensure the startupapicheck is only scheduled on Linux nodes in the helm chart ([#5136](https://togithub.com/cert-manager/cert-manager/issues/5136), [@craigminihan](https://togithub.com/craigminihan))
- Fixed a bug where the Venafi Issuer would not verify its access token (TPP) or API key (Cloud) before becoming ready. Venafi Issuers now remotely verify the access token or API key ([#5212](https://togithub.com/cert-manager/cert-manager/issues/5212), [@jahrlin](https://togithub.com/jahrlin))
- Fixed release artifact archives generated by Make so that a leading `./` is stripped from paths. This ensures that behaviour is the same as v1.7 and earlier ([#5050](https://togithub.com/cert-manager/cert-manager/issues/5050), [@jahrlin](https://togithub.com/jahrlin))
- Increase timeouts for issuer and clusterissuer controllers to 2 minutes and increase ACME client HTTP timeouts to 90 seconds, in order to enable the use of slower ACME issuers which take a long time to process certain requests. ([#5226](https://togithub.com/cert-manager/cert-manager/issues/5226), [@SgtCoDFish](https://togithub.com/SgtCoDFish))
- Increases Venafi Issuer timeout for retrieving a certificate increased to 60 seconds, up from 10. This gives TPP instances longer to complete their workflows and make the certificate available before cert-manager times out and re-queues the request. ([#5247](https://togithub.com/cert-manager/cert-manager/issues/5247), [@hawksight](https://togithub.com/hawksight))
- Remove pkg/util/coverage which broke compatibility with go 1.18; thanks [@davidsbond](https://togithub.com/davidsbond) for finding the issue! ([#5032](https://togithub.com/cert-manager/cert-manager/issues/5032), [@SgtCoDFish](https://togithub.com/SgtCoDFish))
- `cmctl` and `kubectl cert-manager` now report their actual versions instead of "canary", fixing issue [#5020](https://togithub.com/cert-manager/cert-manager/issues/5020) ([#5286](https://togithub.com/cert-manager/cert-manager/issues/5286), [@jetstack-bot](https://togithub.com/jetstack-bot))
##### Other (Cleanup or Flake)
- Adds `make update-all` as a convenience target to run before raising a PR ([#5251](https://togithub.com/cert-manager/cert-manager/issues/5251), [@SgtCoDFish](https://togithub.com/SgtCoDFish))
- Adds make targets for updating and verifying CRDs and codegen ([#5242](https://togithub.com/cert-manager/cert-manager/issues/5242), [@SgtCoDFish](https://togithub.com/SgtCoDFish))
- Bump cert-manager's version of Go to 1.18 ([#5152](https://togithub.com/cert-manager/cert-manager/issues/5152), [@lucacome](https://togithub.com/lucacome))
- Bumps distroless base images to their latest versions ([#5222](https://togithub.com/cert-manager/cert-manager/issues/5222), [@irbekrm](https://togithub.com/irbekrm))
- CertificateSigningRequest: no longer mark a request as failed when using the SelfSigned issuer, and the Secret referenced in `experimental.cert-manager.io/private-key-secret-name` doesn't exist. ([#5332](https://togithub.com/cert-manager/cert-manager/issues/5332), [@jetstack-bot](https://togithub.com/jetstack-bot))
- Only require python for the one test we have which needs it, rather than requiring it globally ([#5245](https://togithub.com/cert-manager/cert-manager/issues/5245), [@SgtCoDFish](https://togithub.com/SgtCoDFish))
- Remove deprecated field `securityContext.enabled` from helm chart ([#4721](https://togithub.com/cert-manager/cert-manager/issues/4721), [@Dean-Coakley](https://togithub.com/Dean-Coakley))
- Removes support for networking/v1beta Ingresses in ingress-shim. ([#5250](https://togithub.com/cert-manager/cert-manager/issues/5250), [@irbekrm](https://togithub.com/irbekrm))
- Reverts additional check for ServiceMonitor ([#5202](https://togithub.com/cert-manager/cert-manager/issues/5202), [@irbekrm](https://togithub.com/irbekrm))
- Updates Kubernetes libraries to `v0.24.2`. ([#5097](https://togithub.com/cert-manager/cert-manager/issues/5097), [@lucacome](https://togithub.com/lucacome))
- Updates warning message that is thrown if issuance fails because private key does not match spec, but private key regeneration is disabled. See [https://github.com/cert-manager/cert-manager/pull/5199](https://togithub.com/cert-manager/cert-manager/pull/5199). ([#5199](https://togithub.com/cert-manager/cert-manager/issues/5199), [@irbekrm](https://togithub.com/irbekrm))
### [`v1.8.2`](https://togithub.com/cert-manager/cert-manager/releases/tag/v1.8.2)
[Compare Source](https://togithub.com/cert-manager/cert-manager/compare/v1.8.1...v1.8.2)
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:
- [@JoooostB](https://togithub.com/JoooostB)
- [@fatz](https://togithub.com/fatz)
- [@jgreat](https://togithub.com/jgreat)
- [@sashokbg](https://togithub.com/sashokbg)
- [@mycloudedu](https://togithub.com/mycloudedu)
- [@hadogenes](https://togithub.com/hadogenes)
- [@SudonymTM](https://togithub.com/SudonymTM)
- [@amalucelli](https://togithub.com/amalucelli)
- [@MilheiroSantos](https://togithub.com/MilheiroSantos)
- [@dverbeek84](https://togithub.com/dverbeek84)
- [@kxs-jnadeau](https://togithub.com/kxs-jnadeau)
- [@fablarosa](https://togithub.com/fablarosa)
- [@nik-nazarov](https://togithub.com/nik-nazarov)
- [@omBratteng](https://togithub.com/omBratteng)
- [@shubham-root](https://togithub.com/shubham-root)
- [@alphabet5](https://togithub.com/alphabet5)
- [@hawksight](https://togithub.com/hawksight)
Thanks also to the cert-manager maintainers who were involved in reviewing this fix and helping to move things forwards:
- [@SgtCoDFish](https://togithub.com/SgtCoDFish)
- [@irbekrm](https://togithub.com/irbekrm)
- [@jahrlin](https://togithub.com/jahrlin)
- [@maelvls](https://togithub.com/maelvls)
- [@JoshVanL](https://togithub.com/JoshVanL)
- [@wallrj](https://togithub.com/wallrj)
- [@jakexks](https://togithub.com/jakexks)
- [@munnerz](https://togithub.com/munnerz)
##### Changes since v1.8.1
##### Bug
- Increase timeouts for issuer and clusterissuer controllers to 2 minutes and increase ACME client HTTP timeouts to 90 seconds, in order to enable the use of slower ACME issuers which take a long time to process certain requests. ([#5231](https://togithub.com/cert-manager/cert-manager/pull/5231), [@JoooostB](https://togithub.com/JoooostB) [@SgtCoDFish](https://togithub.com/SgtCoDFish))
##### Other (Cleanup)
- Bump distroless base images to latest versions ([#5235](https://togithub.com/cert-manager/cert-manager/pull/5235), [@SgtCoDFish](https://togithub.com/SgtCoDFish))
### [`v1.8.1`](https://togithub.com/cert-manager/cert-manager/releases/tag/v1.8.1)
[Compare Source](https://togithub.com/cert-manager/cert-manager/compare/v1.8.0...v1.8.1)
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.
#### Changelog since cert-manager 1.7.1
- Reverts a check for Prometheus APIs before creating cert-manager ServiceMonitors which broke users' GitOps flows ([cert-manager#5204](https://togithub.com/cert-manager/cert-manager/pull/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](https://togithub.com/cert-manager/cert-manager/pull/5203), [@irbekrm](https://togithub.com/irbekrm) )
### [`v1.8.0`](https://togithub.com/cert-manager/cert-manager/releases/tag/v1.8.0)
[Compare Source](https://togithub.com/cert-manager/cert-manager/compare/v1.7.3...v1.8.0)
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`
##### Breaking Changes (You MUST read this before you upgrade!)
##### Validation of the `rotationPolicy` field
The 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](https://cert-manager.io/docs/installation/upgrading/upgrading-1.7-1.8/). ([#4913](https://togithub.com/cert-manager/cert-manager/pull/4913), [@jahrlin](https://togithub.com/jahrlin))
##### What happens if I upgrade to 1.8.0 without doing the above steps?
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:
```text
Certificate.cert-manager.io "my-cert" is invalid: spec.privateKey.rotationPolicy: Unsupported value: "Foo": supported values: "Never", "Always".
```
##### Why was this change necessary?
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":
```text
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](https://togithub.com/cert-manager/cert-manager/pull/4913).
##### Changed Container Layouts
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
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 Windows.
##### Changed Import Path
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](https://cert-manager.io/docs/contributing/importing/) 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.
##### Major Themes
##### Server-Side Apply
cert-manager v1.8.0 adds initial support for Kubernetes [Server-Side Apply](https://kubernetes.io/docs/reference/using-api/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.:
```text
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](../../../v1.8-docs/cli/controller/).
##### From Bazel to Make
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.
##### Exponential backoff after a failed issuance
cert-manager v1.8.0 introduces [exponential backoff after failed certificate issuance](https://togithub.com/cert-manager/cert-manager/blob/f8900ad1d8cc9b7c3697d7554911e2959fa56480/design/20220118.certificate-issuance-exponential-backoff.md).
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](../../cli/cmctl/) 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](https://togithub.com/cert-manager/cert-manager/issues/4786).
#### Community
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:
- [@illrill](https://togithub.com/illrill)
- [@tasharnvb](https://togithub.com/tasharnvb)
- [@enj](https://togithub.com/enj)
- [@vhosakot](https://togithub.com/vhosakot)
- [@fvlaicu](https://togithub.com/fvlaicu)
- [@andreadecorte](https://togithub.com/andreadecorte)
- [@davidsbond](https://togithub.com/davidsbond)
- [@4molybdenum2](https://togithub.com/4molybdenum2)
- [@ajvn](https://togithub.com/ajvn)
- [@mikebryant](https://togithub.com/mikebryant)
- [@jayme-github](https://togithub.com/jayme-github)
Thanks also to the cert-manager maintainer team involved with this release
- [@maelvls](https://togithub.com/maelvls) (Release lead)
- [@SgtCoDFish](https://togithub.com/SgtCoDFish) (Release lead)
- [@jakexks](https://togithub.com/jakexks)
- [@JoshVanL](https://togithub.com/JoshVanL)
- [@irbekrm](https://togithub.com/irbekrm)
- [@wallrj](https://togithub.com/wallrj)
- [@jahrlin](https://togithub.com/jahrlin)
- [@munnerz](https://togithub.com/munnerz)
#### Changelog since v1.7.0
##### Feature
- ACTION REQUIRED: The 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. ([#4913](https://togithub.com/cert-manager/cert-manager/pull/4913), [@jahrlin](https://togithub.com/jahrlin))
- Build: add make targets for running unit and integration tests, as part of the Bazel replacement. ([#4865](https://togithub.com/cert-manager/cert-manager/pull/4865), [@SgtCoDFish](https://togithub.com/SgtCoDFish))
- Build: add make targets for running the end-to-end tests, as part of the Bazel replacement. ([#4914](https://togithub.com/cert-manager/cert-manager/pull/4914), [@maelvls](https://togithub.com/maelvls))
- cert-manager now supports the field `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](https://togithub.com/cert-manager/cert-manager/pull/4957), [@enj](https://togithub.com/enj))
- cert-manager now properly updates the content of the data keys `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](https://togithub.com/cert-manager/cert-manager/pull/4813), [@JoshVanL](https://togithub.com/JoshVanL))
- ClusterRoles aggregation to user-facing admin/edit/view ClusterRoles can be optionally turned off ([#4937](https://togithub.com/cert-manager/cert-manager/pull/4937), [@illrill](https://togithub.com/illrill))
- ACTION REQUIRED: Server-Side Apply: the feature gate `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](https://togithub.com/cert-manager/cert-manager/pull/4811), [@JoshVanL](https://togithub.com/JoshVanL))
- Server-Side Apply: the feature gate `ServerSideApply=true` configures the `certificaterequests-*` controllers to use Kubernetes Server-Side Apply on CertificateRequest resources. ([#4792](https://togithub.com/cert-manager/cert-manager/pull/4792), [@JoshVanL](https://togithub.com/JoshVanL))
- Server-Side Apply: the feature gate `ServerSideApply=true` configures the `certificates-*` controllers to use Kubernetes Server-Side Apply on Certificate resources. ([#4777](https://togithub.com/cert-manager/cert-manager/pull/4777), [@JoshVanL](https://togithub.com/JoshVanL))
- Server-Side Apply: the feature gate `ServerSideApply=true` configures the CertificateSigningRequest controllers to use Kubernetes Server-Side Apply on CertificateSigningRequest resources. ([#4798](https://togithub.com/cert-manager/cert-manager/pull/4798), [@JoshVanL](https://togithub.com/JoshVanL))
- Server-Side Apply: the feature gate `ServerSideApply=true` configures the `issuers` and `clusterissuers` controllers to use Kubernetes Server-Side Apply on Issuer and ClusterIssuer resources. ([#4794](https://togithub.com/cert-manager/cert-manager/pull/4794), [@JoshVanL](https://togithub.com/JoshVanL))
- Server-Side Apply: the feature gate `ServerSideApply=true` configures the `orders` controller to use Kubernetes Server-Side Apply on Order resources. ([#4799](https://togithub.com/cert-manager/cert-manager/pull/4799), [@JoshVanL](https://togithub.com/JoshVanL))
- The annotation `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](https://togithub.com/cert-manager/cert-manager/pull/4973), [@irbekrm](https://togithub.com/irbekrm))
- The annotation `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](https://togithub.com/cert-manager/cert-manager/pull/4789), [@tasharnvb](https://togithub.com/tasharnvb))
- The experimental Gateway API support now uses the v1alpha2 CRDs. ([#4791](https://togithub.com/cert-manager/cert-manager/pull/4791), [@jakexks](https://togithub.com/jakexks))
- The user-agent used by cert-manager in its Kubernetes API clients and ACME clients now takes the form `cert-manager-/ (/) cert-manager/`. 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-`. ([#4773](https://togithub.com/cert-manager/cert-manager/pull/4773), [@JoshVanL](https://togithub.com/JoshVanL))
- You can now uninstall cert-manager using the command `cmctl experimental uninstall`. ([#4897](https://togithub.com/cert-manager/cert-manager/pull/4897), [@jahrlin](https://togithub.com/jahrlin))
- You can now use an external issuer resource as the default issuer when using the Ingress shim feature. The default issuer can be set using the flags `--default-issuer-group`, `--default-issuer-kind`, and `--default-issuer-name`. ([#4833](https://togithub.com/cert-manager/cert-manager/pull/4833), [@jakexks](https://togithub.com/jakexks))
##### Design
- ACTION REQUIRED: The import path for cert-manager has been updated to `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](https://togithub.com/cert-manager/cert-manager/pull/4587), [@SgtCoDFish](https://togithub.com/SgtCoDFish))
##### Bug or Regression
- ACTION REQUIRED: The field `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](https://togithub.com/cert-manager/cert-manager/pull/4814), [@JoshVanL](https://togithub.com/JoshVanL))
- The Go version used to build the cert-manager binaries has been bumped to 1.17.8 to fix a slew of CVEs (none of which were likely to be exploited). ([#4970](https://togithub.com/cert-manager/cert-manager/pull/4970), [@vhosakot](https://togithub.com/vhosakot))
- Helm: the default nodeSelector is now `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](https://togithub.com/cert-manager/cert-manager/pull/3605), [@mikebryant](https://togithub.com/mikebryant))
- Use multivalue records instead of simple records for the AWS Route53 ACME DNS challenge solver, to allow for multiple challenges for the same domain at the same time ([#4793](https://togithub.com/cert-manager/cert-manager/pull/4793), [@fvlaicu](https://togithub.com/fvlaicu))
##### Other (Cleanup or Flake)
- Aggregated admin and edit roles will now include permissions to update certificates' status, which will allow namespace admins and editors to run the `cmctl renew` command in their namespaces. ([#4955](https://togithub.com/cert-manager/cert-manager/pull/4955), [@andreadecorte](https://togithub.com/andreadecorte))
- Cleanup: No longer log an error when cert-manager encounters a conflict in the secrets manager, in favor of always force applying. ([#4815](https://togithub.com/cert-manager/cert-manager/pull/4815), [@JoshVanL](https://togithub.com/JoshVanL))
- Failed certificate issuances are now retried with an exponential backoff where the backoff periods are `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](https://togithub.com/cert-manager/cert-manager/pull/4772), [@irbekrm](https://togithub.com/irbekrm))
- When starting up, cert-manager now solely relies on Lease objects to perform the leader election. Previously, cert-manager supported both ConfigMap and Lease objects for leader election. Existing ConfigMap resources used for leader election will remain and will need deleting manually. A side effect of this is that you cannot upgrade to v1.8.0 from cert-manager 1.3 (although upgrading multiple versions at a time was never supported). ([#4935](https://togithub.com/cert-manager/cert-manager/pull/4935), [@davidsbond](https://togithub.com/davidsbond))
- Helm: you can now set custom labels on the ServiceAccount resources using the values `serviceAccount.labels`, `cainjector.serviceAccount.labels`, `webhook.serviceAccount.labels`, and `startupapicheck.serviceAccount.labels`. ([#4932](https://togithub.com/cert-manager/cert-manager/pull/4932), [@4molybdenum2](https://togithub.com/4molybdenum2))
##### Uncategorized
- Introducing a new metric `controller_sync_error_count` counting the number of errors during sync() of a controller. ([#4987](https://togithub.com/cert-manager/cert-manager/pull/4987), [@jayme-github](https://togithub.com/jayme-github))
- When creating an acmesolver pod, cert-manager now sets `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](https://togithub.com/cert-manager/cert-manager/pull/4953), [@ajvn](https://togithub.com/ajvn))
### [`v1.7.3`](https://togithub.com/cert-manager/cert-manager/releases/tag/v1.7.3)
[Compare Source](https://togithub.com/cert-manager/cert-manager/compare/v1.7.2...v1.7.3)
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:
- [@JoooostB](https://togithub.com/JoooostB)
- [@fatz](https://togithub.com/fatz)
- [@jgreat](https://togithub.com/jgreat)
- [@sashokbg](https://togithub.com/sashokbg)
- [@mycloudedu](https://togithub.com/mycloudedu)
- [@hadogenes](https://togithub.com/hadogenes)
- [@SudonymTM](https://togithub.com/SudonymTM)
- [@amalucelli](https://togithub.com/amalucelli)
- [@MilheiroSantos](https://togithub.com/MilheiroSantos)
- [@dverbeek84](https://togithub.com/dverbeek84)
- [@kxs-jnadeau](https://togithub.com/kxs-jnadeau)
- [@fablarosa](https://togithub.com/fablarosa)
- [@nik-nazarov](https://togithub.com/nik-nazarov)
- [@omBratteng](https://togithub.com/omBratteng)
- [@shubham-root](https://togithub.com/shubham-root)
- [@alphabet5](https://togithub.com/alphabet5)
- [@hawksight](https://togithub.com/hawksight)
Thanks also to the cert-manager maintainers who were involved in reviewing this fix and helping to move things forwards:
- [@irbekrm](https://togithub.com/irbekrm)
- [@jahrlin](https://togithub.com/jahrlin)
- [@maelvls](https://togithub.com/maelvls)
- [@JoshVanL](https://togithub.com/JoshVanL)
- [@wallrj](https://togithub.com/wallrj)
- [@jakexks](https://togithub.com/jakexks)
- [@munnerz](https://togithub.com/munnerz)
#### Changes since v1.7.2
##### Bug
- Increase timeouts for issuer and clusterissuer controllers to 2 minutes and increase ACME client HTTP timeouts to 90 seconds, in order to enable the use of slower ACME issuers which take a long time to process certain requests. ([#5232](https://togithub.com/cert-manager/cert-manager/pull/5232), [@JoooostB](https://togithub.com/JoooostB) [@SgtCoDFish](https://togithub.com/SgtCoDFish))
##### Other (Cleanup)
- Bumps go to 1.17.11 and base images to latest distroless base images ([#5234](https://togithub.com/cert-manager/cert-manager/pull/5234), [@SgtCoDFish](https://togithub.com/SgtCoDFish))
### [`v1.7.2`](https://togithub.com/cert-manager/cert-manager/releases/tag/v1.7.2)
[Compare Source](https://togithub.com/cert-manager/cert-manager/compare/v1.7.1...v1.7.2)
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.
### Changelog since cert-manager 1.7.1
##### Bug or Regression
- Bumps the version of Go used to build the cert-manager binaries to 1.17.8, to fix a slew of CVEs (none of which were likely to be exploited) ([#4976 ](https://togithub.com/cert-manager/cert-manager/pull/4976), [@vhosakot](https://togithub.com/vhosakot))
- Fixes an expired hardcoded certificate which broke unit tests ([#4978](https://togithub.com/cert-manager/cert-manager/pull/4978), [@SgtCoDFish](https://togithub.com/SgtCoDFish) [@jakexks](https://togithub.com/jakexks))
### [`v1.7.1`](https://togithub.com/cert-manager/cert-manager/releases/tag/v1.7.1)
[Compare Source](https://togithub.com/cert-manager/cert-manager/compare/v1.7.0...v1.7.1)
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.
#### Changelog since v1.7.0
##### Bug or Regression
- Fix: The alpha feature Certificate's `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](https://togithub.com/cert-manager/cert-manager/issues/4816), [@JoshVanL](https://togithub.com/JoshVanL))
### [`v1.7.0`](https://togithub.com/cert-manager/cert-manager/releases/tag/v1.7.0)
[Compare Source](https://togithub.com/cert-manager/cert-manager/compare/v1.6.3...v1.7.0)
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.
#### Breaking Changes (You **MUST** read this before you upgrade!)
##### Removal of Deprecated APIs
⚠ 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`][download cmctl-v1.7.0] and read [Migrating Deprecated API Resources] for full instructions.
[download `cmctl-v1.7.0`]: https://togithub.com/jetstack/cert-manager/releases/tag/v1.7.0
[Migrating Deprecated API Resources]: https://cert-manager.io/docs/installation/upgrading/remove-deprecated-apis/
##### Ingress Class Semantics
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:
```yaml
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:
```yaml
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].
[notes on Ingress v1 compatibility]: https://cert-manager.io/docs/installation/upgrading/ingress-class-compatibility/
##### Upgrading with Server Side Apply
As part of the work to [remove deprecated APIs](#removal-of-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 `. This can be solved either by performing the upgrade with client side apply or by manually patching the [managed fields](https://kubernetes.io/docs/reference/using-api/server-side-apply/#field-management) of cert-manager `CustomResourceDefinitions`:
```bash
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](https://togithub.com/stevehipwell) for the above patch commands!)
See the original GitHub issue [`cert-manager#4831`](https://togithub.com/cert-manager/cert-manager/issues/4831)
#### Major Themes
##### Removal of Deprecated APIs
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.
##### Additional Certificate Output Formats
`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](https://togithub.com/seuf) for getting this across the line!
[Additional Certificate Output Formats]: https://cert-manager.io/docs/usage/certificate/#additional-certificate-output-formats
##### Server-Side Apply
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](https://cert-manager.io/docs/installation/supported-releases/) for further compatibility details).
[Server-Side Apply]: https://kubernetes.io/docs/reference/using-api/server-side-apply/
##### Configuration Files
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.
[WebhookConfiguration Schema]: https://cert-manager.io/next-docs/reference/api-docs/#webhook.config.cert-manager.io/v1alpha1.WebhookConfiguration
##### Developing cert-manager Without Bazel
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][Bazel -> Make Migration Tracker], 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/...`.
[Bazel -> Make Migration Tracker]: https://togithub.com/jetstack/cert-manager/issues/4712
#### Community
Thanks again to all open-source contributors with commits in this release, including:
- [@Adphi](https://togithub.com/Adphi)
- [@devholic](https://togithub.com/devholic)
- [@johnwchadwick](https://togithub.com/johnwchadwick)
- [@jsoref](https://togithub.com/jsoref)
- [@jwenz723](https://togithub.com/jwenz723)
- [@seuf](https://togithub.com/seuf)
- [@thirdeyenick](https://togithub.com/thirdeyenick)
Thanks as usual to [@coderanger](https://togithub.com/coderanger) for helping people out on the [`#cert-manager` Slack channel][#cert-manager Slack channel]; it's a huge help and much appreciated.
In addition, the following cert-manager maintainers were involved in this release:
- [@munnerz](https://togithub.com/munnerz)
- [@JoshVanL](https://togithub.com/JoshVanL)
- [@irbekrm](https://togithub.com/irbekrm)
- [@wallrj](https://togithub.com/wallrj)
- [@maelvls](https://togithub.com/maelvls)
- [@SgtCoDFish](https://togithub.com/SgtCoDFish)
- [@jakexks](https://togithub.com/jakexks)
- [@jahrlin](https://togithub.com/jahrlin)
[`#cert-manager` Slack channel]: https://cert-manager.io/docs/contributing/#slack
#### Changelog since v1.6.0
##### Feature
- Add `--acme-http01-solver-nameservers` flag to enable custom nameservers usage for ACME HTT01 challenges propagation checks. ([#4287](https://togithub.com/cert-manager/cert-manager/issues/4287), [@Adphi](https://togithub.com/Adphi))
- Add `cmctl upgrade migrate-api-version` to ensure all CRD resources are stored at 'v1' prior to upgrading to v1.7 onwards ([#4711](https://togithub.com/cert-manager/cert-manager/issues/4711), [@munnerz](https://togithub.com/munnerz))
- Add goimports verification step for CI ([#4710](https://togithub.com/cert-manager/cert-manager/issues/4710), [@SgtCoDFish](https://togithub.com/SgtCoDFish))
- Add support for loading webhook flags/options from a WebhookConfiguration file on disk ([#4546](https://togithub.com/cert-manager/cert-manager/issues/4546), [@munnerz](https://togithub.com/munnerz))
- Added `additionalOutputFormats` parameter to allow `DER` (binary) and `CombinedPEM` (key + cert bundle) formats. ([#4598](https://togithub.com/cert-manager/cert-manager/issues/4598), [@seuf](https://togithub.com/seuf))
- Added a makefile based build workflow which doesn't depend on bazel ([#4554](https://togithub.com/cert-manager/cert-manager/issues/4554), [@SgtCoDFish](https://togithub.com/SgtCoDFish))
- Added a new Helm chart parameter `prometheus.servicemonitor.honorLabels`, which sets the `honor_labels` field of the Prometheus scrape config. ([#4608](https://togithub.com/cert-manager/cert-manager/issues/4608), [@thirdeyenick](https://togithub.com/thirdeyenick))
- Breaking change: pprof now runs by default on localhost:6060 for webhook and controller, but only if explicitly enabled. Pprof can now be enabled also for cainjector. All three components have `--enable-profiling`, `--profiler-address` CLI flags to configure profiling. Thanks to [@bitscuit](https://togithub.com/bitscuit) for help with this! ([#4550](https://togithub.com/cert-manager/cert-manager/issues/4550), [@irbekrm](https://togithub.com/irbekrm))
- Certificate Secrets are now managed by the APPLY API call, rather than UPDATE/CREATE. The issuing controller actively reconciles Certificate SecretTemplate's against corresponding Secrets, garbage collecting and correcting key/value changes. ([#4638](https://togithub.com/cert-manager/cert-manager/issues/4638), [@JoshVanL](https://togithub.com/JoshVanL))
##### Bug or Regression
- Ensures 1 hour backoff between errored calls for new ACME Orders. ([#4616](https://togithub.com/cert-manager/cert-manager/issues/4616), [@irbekrm](https://togithub.com/irbekrm))
- Fix unexpected exit when multiple DNS providers are passed to `RunWebhookServer` ([#4702](https://togithub.com/cert-manager/cert-manager/issues/4702), [@devholic](https://togithub.com/devholic))
- Fixed a bug in the way the Helm chart handles service annotations on the controller and webhook services. ([#4329](https://togithub.com/cert-manager/cert-manager/issues/4329), [@jwenz723](https://togithub.com/jwenz723))
- Fixed a bug that can cause `cmctl version` to erroneously display the wrong webhook pod versions when older failed pods are present. ([#4615](https://togithub.co
Configuration
📅 Schedule: Branch creation - "before 2am" in timezone Etc/UTC, Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
[ ] If you want to rebase/retry this PR, click this checkbox.
This PR has been generated by Mend Renovate. View repository job log here.
This PR contains the following updates:
1.6.1->v1.9.1Release Notes
cert-manager/cert-manager
### [`v1.9.1`](https://togithub.com/cert-manager/cert-manager/releases/tag/v1.9.1) [Compare Source](https://togithub.com/cert-manager/cert-manager/compare/v1.9.0...v1.9.1) 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](https://togithub.com/danquack) and [@ArchiFleKs](https://togithub.com/ArchiFleKs) for raising this issue, and [@danquack](https://togithub.com/danquack) and [@JoshVanL](https://togithub.com/JoshVanL) for fixing it! ##### Changes since v1.9.0 ##### Bug - DNS Route53: Remove incorrect validation which rejects solvers that don't define either a `accessKeyID` or `secretAccessKeyID`. ([#5341](https://togithub.com/cert-manager/cert-manager/pull/5341), [@JoshVanL](https://togithub.com/JoshVanL) [@danquack](https://togithub.com/danquack) ) ### [`v1.9.0`](https://togithub.com/cert-manager/cert-manager/releases/tag/v1.9.0) [Compare Source](https://togithub.com/cert-manager/cert-manager/compare/v1.8.2...v1.9.0) 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. #### Major Themes ##### Literal Certificate Subjects 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](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.6) 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](https://ldapwiki.com/wiki/Directory%20Information%20Tree). See [`cert-manager#3203`](https://togithub.com/cert-manager/cert-manager/issues/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: ```yaml 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. ##### ingress-shim `Certificate` Configuration cert-manager 1.9 adds the ability to configure an ingress-shim `Certificate`'s `spec.revisionHistoryLimit` and `spec.privateKey` via [annotations on the `Ingress` resource](https://cert-manager.io/docs/usage/ingress/#supported-annotations). 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. ##### Contribution Workflow 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](https://cert-manager.io/docs/contributing/policy/) and discussed the process of building cert-manager's [roadmap](https://togithub.com/cert-manager/cert-manager/blob/master/ROADMAP.md). If you're interested in these topics, we're happy to chat about them! ##### `make` Workflow cert-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](https://cert-manager.io/docs/contributing/building/) 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! 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! - [@AcidLeroy](https://togithub.com/AcidLeroy) - [@oGi4i](https://togithub.com/oGi4i) - [@spockz](https://togithub.com/spockz) (and [@yongk802](https://togithub.com/yongk802) who raised a similar PR) - [@andrewgkew](https://togithub.com/andrewgkew) - [@sveba](https://togithub.com/sveba) - [@rodrigorfk](https://togithub.com/rodrigorfk) - [@craigminihan](https://togithub.com/craigminihan) - [@lucacome](https://togithub.com/lucacome) - [@Dean-Coakley](https://togithub.com/Dean-Coakley) - [@Compy](https://togithub.com/Compy) Thanks also to the following maintainers who worked on cert-manager 1.9: - [@irbekrm](https://togithub.com/irbekrm) - [@SgtCoDFish](https://togithub.com/SgtCoDFish) - [@jakexks](https://togithub.com/jakexks) - [@wallrj](https://togithub.com/wallrj) - [@maelvls](https://togithub.com/maelvls) - [@JoshVanL](https://togithub.com/JoshVanL) - [@jahrlin](https://togithub.com/jahrlin) - [@munnerz](https://togithub.com/munnerz) #### Changes since v1.8.0 ##### Feature - Added support for pulling both AWS access key IDs and secret keys from Kubernetes secrets ([#5194](https://togithub.com/cert-manager/cert-manager/issues/5194), [@Compy](https://togithub.com/Compy)) - Adds `make clean-all` for starting a fresh development environment and `make which-go` for getting go version information when developing cert-manager ([#5118](https://togithub.com/cert-manager/cert-manager/issues/5118), [@SgtCoDFish](https://togithub.com/SgtCoDFish)) - Adds `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](https://togithub.com/cert-manager/cert-manager/issues/5205), [@SgtCoDFish](https://togithub.com/SgtCoDFish)) - Adds a new alpha Prometheus summary vector metric `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](https://togithub.com/cert-manager/cert-manager/issues/5053), [@irbekrm](https://togithub.com/irbekrm)) - Adds more verbose logging info for certificate renewal in the DynamicSource webhook to include DNSNames ([#5142](https://togithub.com/cert-manager/cert-manager/issues/5142), [@AcidLeroy](https://togithub.com/AcidLeroy)) - Adds new LICENSES format and ability to verify and update licenses through make ([#5243](https://togithub.com/cert-manager/cert-manager/issues/5243), [@SgtCoDFish](https://togithub.com/SgtCoDFish)) - Adds private key Ingress annotations to set private key properties for Certificate ([#5239](https://togithub.com/cert-manager/cert-manager/issues/5239), [@oGi4i](https://togithub.com/oGi4i)) - Adds the `cert-manager.io/revision-history-limit` annotation for Ingress resources, to limit the number of CertificateRequests which are kept for a Certificate ([#5221](https://togithub.com/cert-manager/cert-manager/issues/5221), [@oGi4i](https://togithub.com/oGi4i)) - Adds the `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](https://togithub.com/cert-manager/cert-manager/issues/5002), [@spockz](https://togithub.com/spockz)) - Change default build dir from `bin` to `_bin`, which plays better with certain tools which might treat `bin` as just another source directory ([#5130](https://togithub.com/cert-manager/cert-manager/issues/5130), [@SgtCoDFish](https://togithub.com/SgtCoDFish)) - Helm: Adds a new `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](https://togithub.com/cert-manager/cert-manager/issues/5141), [@andrewgkew](https://togithub.com/andrewgkew)) - Helm: Allow for users to not auto-mount service account tokens [see also k/k#57601](https://togithub.com/kubernetes/kubernetes/issues/57601) ([#5016](https://togithub.com/cert-manager/cert-manager/issues/5016), [@sveba](https://togithub.com/sveba)) - Use multiple retries when provisioning tools using `curl`, to reduce flakes in tests and development environments ([#5272](https://togithub.com/cert-manager/cert-manager/issues/5272), [@SgtCoDFish](https://togithub.com/SgtCoDFish)) ##### Bug or Regression - CertificateRequests controllers must wait for the core secrets informer to be synced ([#5224](https://togithub.com/cert-manager/cert-manager/issues/5224), [@rodrigorfk](https://togithub.com/rodrigorfk)) - Ensure that `make release-artifacts` only builds unsigned artifacts as intended ([#5181](https://togithub.com/cert-manager/cert-manager/issues/5181), [@SgtCoDFish](https://togithub.com/SgtCoDFish)) - Ensure the startupapicheck is only scheduled on Linux nodes in the helm chart ([#5136](https://togithub.com/cert-manager/cert-manager/issues/5136), [@craigminihan](https://togithub.com/craigminihan)) - Fixed a bug where the Venafi Issuer would not verify its access token (TPP) or API key (Cloud) before becoming ready. Venafi Issuers now remotely verify the access token or API key ([#5212](https://togithub.com/cert-manager/cert-manager/issues/5212), [@jahrlin](https://togithub.com/jahrlin)) - Fixed release artifact archives generated by Make so that a leading `./` is stripped from paths. This ensures that behaviour is the same as v1.7 and earlier ([#5050](https://togithub.com/cert-manager/cert-manager/issues/5050), [@jahrlin](https://togithub.com/jahrlin)) - Increase timeouts for issuer and clusterissuer controllers to 2 minutes and increase ACME client HTTP timeouts to 90 seconds, in order to enable the use of slower ACME issuers which take a long time to process certain requests. ([#5226](https://togithub.com/cert-manager/cert-manager/issues/5226), [@SgtCoDFish](https://togithub.com/SgtCoDFish)) - Increases Venafi Issuer timeout for retrieving a certificate increased to 60 seconds, up from 10. This gives TPP instances longer to complete their workflows and make the certificate available before cert-manager times out and re-queues the request. ([#5247](https://togithub.com/cert-manager/cert-manager/issues/5247), [@hawksight](https://togithub.com/hawksight)) - Remove pkg/util/coverage which broke compatibility with go 1.18; thanks [@davidsbond](https://togithub.com/davidsbond) for finding the issue! ([#5032](https://togithub.com/cert-manager/cert-manager/issues/5032), [@SgtCoDFish](https://togithub.com/SgtCoDFish)) - `cmctl` and `kubectl cert-manager` now report their actual versions instead of "canary", fixing issue [#5020](https://togithub.com/cert-manager/cert-manager/issues/5020) ([#5286](https://togithub.com/cert-manager/cert-manager/issues/5286), [@jetstack-bot](https://togithub.com/jetstack-bot)) ##### Other (Cleanup or Flake) - Adds `make update-all` as a convenience target to run before raising a PR ([#5251](https://togithub.com/cert-manager/cert-manager/issues/5251), [@SgtCoDFish](https://togithub.com/SgtCoDFish)) - Adds make targets for updating and verifying CRDs and codegen ([#5242](https://togithub.com/cert-manager/cert-manager/issues/5242), [@SgtCoDFish](https://togithub.com/SgtCoDFish)) - Bump cert-manager's version of Go to 1.18 ([#5152](https://togithub.com/cert-manager/cert-manager/issues/5152), [@lucacome](https://togithub.com/lucacome)) - Bumps distroless base images to their latest versions ([#5222](https://togithub.com/cert-manager/cert-manager/issues/5222), [@irbekrm](https://togithub.com/irbekrm)) - CertificateSigningRequest: no longer mark a request as failed when using the SelfSigned issuer, and the Secret referenced in `experimental.cert-manager.io/private-key-secret-name` doesn't exist. ([#5332](https://togithub.com/cert-manager/cert-manager/issues/5332), [@jetstack-bot](https://togithub.com/jetstack-bot)) - Only require python for the one test we have which needs it, rather than requiring it globally ([#5245](https://togithub.com/cert-manager/cert-manager/issues/5245), [@SgtCoDFish](https://togithub.com/SgtCoDFish)) - Remove deprecated field `securityContext.enabled` from helm chart ([#4721](https://togithub.com/cert-manager/cert-manager/issues/4721), [@Dean-Coakley](https://togithub.com/Dean-Coakley)) - Removes support for networking/v1beta Ingresses in ingress-shim. ([#5250](https://togithub.com/cert-manager/cert-manager/issues/5250), [@irbekrm](https://togithub.com/irbekrm)) - Reverts additional check for ServiceMonitor ([#5202](https://togithub.com/cert-manager/cert-manager/issues/5202), [@irbekrm](https://togithub.com/irbekrm)) - Updates Kubernetes libraries to `v0.24.2`. ([#5097](https://togithub.com/cert-manager/cert-manager/issues/5097), [@lucacome](https://togithub.com/lucacome)) - Updates warning message that is thrown if issuance fails because private key does not match spec, but private key regeneration is disabled. See [https://github.com/cert-manager/cert-manager/pull/5199](https://togithub.com/cert-manager/cert-manager/pull/5199). ([#5199](https://togithub.com/cert-manager/cert-manager/issues/5199), [@irbekrm](https://togithub.com/irbekrm)) ### [`v1.8.2`](https://togithub.com/cert-manager/cert-manager/releases/tag/v1.8.2) [Compare Source](https://togithub.com/cert-manager/cert-manager/compare/v1.8.1...v1.8.2) 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: - [@JoooostB](https://togithub.com/JoooostB) - [@fatz](https://togithub.com/fatz) - [@jgreat](https://togithub.com/jgreat) - [@sashokbg](https://togithub.com/sashokbg) - [@mycloudedu](https://togithub.com/mycloudedu) - [@hadogenes](https://togithub.com/hadogenes) - [@SudonymTM](https://togithub.com/SudonymTM) - [@amalucelli](https://togithub.com/amalucelli) - [@MilheiroSantos](https://togithub.com/MilheiroSantos) - [@dverbeek84](https://togithub.com/dverbeek84) - [@kxs-jnadeau](https://togithub.com/kxs-jnadeau) - [@fablarosa](https://togithub.com/fablarosa) - [@nik-nazarov](https://togithub.com/nik-nazarov) - [@omBratteng](https://togithub.com/omBratteng) - [@shubham-root](https://togithub.com/shubham-root) - [@alphabet5](https://togithub.com/alphabet5) - [@hawksight](https://togithub.com/hawksight) Thanks also to the cert-manager maintainers who were involved in reviewing this fix and helping to move things forwards: - [@SgtCoDFish](https://togithub.com/SgtCoDFish) - [@irbekrm](https://togithub.com/irbekrm) - [@jahrlin](https://togithub.com/jahrlin) - [@maelvls](https://togithub.com/maelvls) - [@JoshVanL](https://togithub.com/JoshVanL) - [@wallrj](https://togithub.com/wallrj) - [@jakexks](https://togithub.com/jakexks) - [@munnerz](https://togithub.com/munnerz) ##### Changes since v1.8.1 ##### Bug - Increase timeouts for issuer and clusterissuer controllers to 2 minutes and increase ACME client HTTP timeouts to 90 seconds, in order to enable the use of slower ACME issuers which take a long time to process certain requests. ([#5231](https://togithub.com/cert-manager/cert-manager/pull/5231), [@JoooostB](https://togithub.com/JoooostB) [@SgtCoDFish](https://togithub.com/SgtCoDFish)) ##### Other (Cleanup) - Bump distroless base images to latest versions ([#5235](https://togithub.com/cert-manager/cert-manager/pull/5235), [@SgtCoDFish](https://togithub.com/SgtCoDFish)) ### [`v1.8.1`](https://togithub.com/cert-manager/cert-manager/releases/tag/v1.8.1) [Compare Source](https://togithub.com/cert-manager/cert-manager/compare/v1.8.0...v1.8.1) 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. #### Changelog since cert-manager 1.7.1 - Reverts a check for Prometheus APIs before creating cert-manager ServiceMonitors which broke users' GitOps flows ([cert-manager#5204](https://togithub.com/cert-manager/cert-manager/pull/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](https://togithub.com/cert-manager/cert-manager/pull/5203), [@irbekrm](https://togithub.com/irbekrm) ) ### [`v1.8.0`](https://togithub.com/cert-manager/cert-manager/releases/tag/v1.8.0) [Compare Source](https://togithub.com/cert-manager/cert-manager/compare/v1.7.3...v1.8.0) 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` ##### Breaking Changes (You MUST read this before you upgrade!) ##### Validation of the `rotationPolicy` field The 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](https://cert-manager.io/docs/installation/upgrading/upgrading-1.7-1.8/). ([#4913](https://togithub.com/cert-manager/cert-manager/pull/4913), [@jahrlin](https://togithub.com/jahrlin)) ##### What happens if I upgrade to 1.8.0 without doing the above steps? 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: ```text Certificate.cert-manager.io "my-cert" is invalid: spec.privateKey.rotationPolicy: Unsupported value: "Foo": supported values: "Never", "Always". ``` ##### Why was this change necessary? 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": ```text 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](https://togithub.com/cert-manager/cert-manager/pull/4913). ##### Changed Container Layouts 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 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 Windows. ##### Changed Import Path 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](https://cert-manager.io/docs/contributing/importing/) 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. ##### Major Themes ##### Server-Side Apply cert-manager v1.8.0 adds initial support for Kubernetes [Server-Side Apply](https://kubernetes.io/docs/reference/using-api/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.: ```text 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](../../../v1.8-docs/cli/controller/). ##### From Bazel to Make 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. ##### Exponential backoff after a failed issuance cert-manager v1.8.0 introduces [exponential backoff after failed certificate issuance](https://togithub.com/cert-manager/cert-manager/blob/f8900ad1d8cc9b7c3697d7554911e2959fa56480/design/20220118.certificate-issuance-exponential-backoff.md). 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](../../cli/cmctl/) 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](https://togithub.com/cert-manager/cert-manager/issues/4786). #### Community 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: - [@illrill](https://togithub.com/illrill) - [@tasharnvb](https://togithub.com/tasharnvb) - [@enj](https://togithub.com/enj) - [@vhosakot](https://togithub.com/vhosakot) - [@fvlaicu](https://togithub.com/fvlaicu) - [@andreadecorte](https://togithub.com/andreadecorte) - [@davidsbond](https://togithub.com/davidsbond) - [@4molybdenum2](https://togithub.com/4molybdenum2) - [@ajvn](https://togithub.com/ajvn) - [@mikebryant](https://togithub.com/mikebryant) - [@jayme-github](https://togithub.com/jayme-github) Thanks also to the cert-manager maintainer team involved with this release - [@maelvls](https://togithub.com/maelvls) (Release lead) - [@SgtCoDFish](https://togithub.com/SgtCoDFish) (Release lead) - [@jakexks](https://togithub.com/jakexks) - [@JoshVanL](https://togithub.com/JoshVanL) - [@irbekrm](https://togithub.com/irbekrm) - [@wallrj](https://togithub.com/wallrj) - [@jahrlin](https://togithub.com/jahrlin) - [@munnerz](https://togithub.com/munnerz) #### Changelog since v1.7.0 ##### Feature - ACTION REQUIRED: The 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. ([#4913](https://togithub.com/cert-manager/cert-manager/pull/4913), [@jahrlin](https://togithub.com/jahrlin)) - Build: add make targets for running unit and integration tests, as part of the Bazel replacement. ([#4865](https://togithub.com/cert-manager/cert-manager/pull/4865), [@SgtCoDFish](https://togithub.com/SgtCoDFish)) - Build: add make targets for running the end-to-end tests, as part of the Bazel replacement. ([#4914](https://togithub.com/cert-manager/cert-manager/pull/4914), [@maelvls](https://togithub.com/maelvls)) - cert-manager now supports the field `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](https://togithub.com/cert-manager/cert-manager/pull/4957), [@enj](https://togithub.com/enj)) - cert-manager now properly updates the content of the data keys `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](https://togithub.com/cert-manager/cert-manager/pull/4813), [@JoshVanL](https://togithub.com/JoshVanL)) - ClusterRoles aggregation to user-facing admin/edit/view ClusterRoles can be optionally turned off ([#4937](https://togithub.com/cert-manager/cert-manager/pull/4937), [@illrill](https://togithub.com/illrill)) - ACTION REQUIRED: Server-Side Apply: the feature gate `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](https://togithub.com/cert-manager/cert-manager/pull/4811), [@JoshVanL](https://togithub.com/JoshVanL)) - Server-Side Apply: the feature gate `ServerSideApply=true` configures the `certificaterequests-*` controllers to use Kubernetes Server-Side Apply on CertificateRequest resources. ([#4792](https://togithub.com/cert-manager/cert-manager/pull/4792), [@JoshVanL](https://togithub.com/JoshVanL)) - Server-Side Apply: the feature gate `ServerSideApply=true` configures the `certificates-*` controllers to use Kubernetes Server-Side Apply on Certificate resources. ([#4777](https://togithub.com/cert-manager/cert-manager/pull/4777), [@JoshVanL](https://togithub.com/JoshVanL)) - Server-Side Apply: the feature gate `ServerSideApply=true` configures the CertificateSigningRequest controllers to use Kubernetes Server-Side Apply on CertificateSigningRequest resources. ([#4798](https://togithub.com/cert-manager/cert-manager/pull/4798), [@JoshVanL](https://togithub.com/JoshVanL)) - Server-Side Apply: the feature gate `ServerSideApply=true` configures the `issuers` and `clusterissuers` controllers to use Kubernetes Server-Side Apply on Issuer and ClusterIssuer resources. ([#4794](https://togithub.com/cert-manager/cert-manager/pull/4794), [@JoshVanL](https://togithub.com/JoshVanL)) - Server-Side Apply: the feature gate `ServerSideApply=true` configures the `orders` controller to use Kubernetes Server-Side Apply on Order resources. ([#4799](https://togithub.com/cert-manager/cert-manager/pull/4799), [@JoshVanL](https://togithub.com/JoshVanL)) - The annotation `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](https://togithub.com/cert-manager/cert-manager/pull/4973), [@irbekrm](https://togithub.com/irbekrm)) - The annotation `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](https://togithub.com/cert-manager/cert-manager/pull/4789), [@tasharnvb](https://togithub.com/tasharnvb)) - The experimental Gateway API support now uses the v1alpha2 CRDs. ([#4791](https://togithub.com/cert-manager/cert-manager/pull/4791), [@jakexks](https://togithub.com/jakexks)) - The user-agent used by cert-manager in its Kubernetes API clients and ACME clients now takes the form `cert-manager-Configuration
📅 Schedule: Branch creation - "before 2am" in timezone Etc/UTC, Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate. View repository job log here.