Update Helm release cert-manager to v1.9.1#189
Open
weaveworksbot wants to merge 2 commits intomainfrom
Open
Conversation
d55e2c2 to
07309a3
Compare
07309a3 to
17dd548
Compare
17dd548 to
22ac833
Compare
22ac833 to
f3cc74a
Compare
f989101 to
11989c8
Compare
11989c8 to
e5e708d
Compare
e5e708d to
f37d56a
Compare
f37d56a to
a7442aa
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v1.8.0->v1.9.1Release Notes
cert-manager/cert-manager
v1.9.1Compare Source
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!
Changes since v1.9.0
Bug
accessKeyIDorsecretAccessKeyID. (#5341, @JoshVanL @danquack )v1.9.0Compare Source
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
Certificates 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 theCertificatecreated via ingress-shim using annotations on theIngressresource; introduces various changes/improvements in contributor flow; and finishes the new make-based contributor workflow.Major Themes
Literal Certificate Subjects
cert-manager's
Certificateallows users to configure the subject fields of the X.509 certificate viaspec.subjectandspec.commonNamefields. 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
Certificatespec. 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
LiteralSubjectfield has been added to theCertificatespec where users can pass a literal RDN sequence:To use this field, the alpha feature gate
LiteralCertificateSubjectneeds to be enabled on both the cert-manager controller and webhook. Bear in mind thatspec.literalSubjectis mutually exclusive withspec.commonNameandspec.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.subjectandspec.commonNamefields 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
CertificateConfigurationcert-manager 1.9 adds the ability to configure an ingress-shim
Certificate'sspec.revisionHistoryLimitandspec.privateKeyvia annotations on theIngressresource.This should allow folks to configure ingress-shim
Certificates according to best practices (i.e by settingCertificate'sspec.privateKey.rotationPolicytoAlways).In the future we would like to design a better mechanism to configure these
Certificates. We advise caution when usingIngressannotations as there is no validation of the annotations atIngresscreation 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 and discussed the process of building cert-manager's roadmap. If you're interested in these topics, we're happy to chat about them!
makeWorkflowcert-manager 1.8 introduced a new
makebased workflow alongside the existing Bazel workflow. The work to improve themakeworkflow was continued in 1.9 and our contributor documentation has been redefined to usemakecommands. 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!
Thanks also to the following maintainers who worked on cert-manager 1.9:
Changes since v1.8.0
Feature
make clean-allfor starting a fresh development environment andmake which-gofor getting go version information when developing cert-manager (#5118, @SgtCoDFish)make upload-releasetarget 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_secondswhich 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-limitannotation for Ingress resources, to limit the number of CertificateRequests which are kept for a Certificate (#5221, @oGi4i)literalSubjectfield for Certificate resources. This is an alpha feature, enabled by passing the flag--feature-gates=LiteralCertificateSubject=trueto the cert-manager controller and webhook.literalSubjectallows 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)binto_bin, which plays better with certain tools which might treatbinas just another source directory (#5130, @SgtCoDFish)namespaceparameter 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)Bug or Regression
make release-artifactsonly 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)cmctlandkubectl cert-managernow report their actual versions instead of "canary", fixing issue #5020 (#5286, @jetstack-bot)Other (Cleanup or Flake)
make update-allas a convenience target to run before raising a PR (#5251, @SgtCoDFish)experimental.cert-manager.io/private-key-secret-namedoesn't exist. (#5332, @jetstack-bot)securityContext.enabledfrom helm chart (#4721, @Dean-Coakley)v0.24.2. (#5097, @lucacome)v1.8.2Compare Source
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:
Changes since v1.8.1
Bug
Other (Cleanup)
v1.8.1Compare Source
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)
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 )
Configuration
📅 Schedule: 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 Renovate Bot.