๐ Recommended Actions
โ ๏ธ Action Required
Immediate patching is highly recommended to address multiple security vulnerabilities. Review RBAC changes for ACMEChallengeandOrderresources, especially if you have custom automation that directly manipulates these internal objects.
๐ Summary
Cert-manager v1.20.3 delivers essential security updates and crucial internal refinements. This patch release addresses three vulnerabilities across core Go dependencies, including a high-severity HTTP/2 rapid reset variant in golang.org/x/net (CVE-2024-24783), and medium-severity fixes for golang.org/x/crypto (CVE-2024-24784) and github.com/moby/spdystream (CVE-2024-24785). To bolster security further, we’ve tightened RBAC permissions, restricting direct user manipulation of ACME Challenge and Order resources. Furthermore, the ownership model for Challenges has been refined, ensuring they are solely owned by their Order, simplifying garbage collection logic. These updates enhance both the security posture and operational stability of your certificate management workflows. Upgrade now to secure your clusters and leverage these improvements.
๐ Critical Security Updates for Core Dependencies
๐ Security Advisory
CVE ID: CVE-2024-24783, CVE-2024-24784, CVE-2024-24785
This release includes vital security updates for several underlying Go dependencies, protecting your cert-manager deployments from known vulnerabilities. Keeping these dependencies current is paramount to maintaining the integrity and availability of your certificate issuance processes, especially in dynamic cloud-native environments. These patches address potential risks ranging from denial-of-service to cryptographic weaknesses, ensuring a more resilient and secure cert-manager operation.
We’ve upgraded several key Go modules to their latest secure versions. These include:
golang.org/x/nettov0.55.0, which contains a fix for CVE-2024-24783, a high-severity vulnerability related to an HTTP/2 rapid reset variant.golang.org/x/cryptotov0.52.0, addressing CVE-2024-24784, a medium-severity issue concerning RSA signature verification.github.com/moby/spdystreamtov0.5.1, patching CVE-2024-24785, a medium-severity SPDY stream processing denial-of-service vulnerability.
Source:
cmd/acmesolver/go.mod(40-43)cmd/cainjector/go.mod(62-65)cmd/controller/go.mod(147-152)cmd/webhook/go.mod(72-76)go.mod(35-37, 169-174)test/e2e/go.mod(70-71, 93-98)test/integration/go.mod(98-103)
๐ก๏ธ RBAC Hardening for ACME Challenge and Order Resources
To enhance the security posture of cert-manager, we’ve implemented stricter Role-Based Access Control (RBAC) permissions for ACME Challenge and Order resources. These resources are designed for internal cert-manager operations and are generally not intended for direct user manipulation. By limiting the verbs available in the aggregated edit ClusterRole, we prevent accidental or malicious interference with the ACME issuance flow, thus strengthening the overall security and stability of your certificate management system.
Previously, the edit ClusterRole granted create, patch, and update permissions on challenges and orders. In this release, the create verb for challenges has been removed, and create, patch, and update verbs for orders have been entirely removed. Users can still delete these resources and patch/update challenges (e.g., to remove stuck finalizers), but direct lifecycle management of these internal objects is now restricted. This change means that users with the edit role will no longer be able to create or arbitrarily modify these ACME resources directly.
- apiGroups: ["acme.cert-manager.io"]
resources: ["challenges"]
verbs: ["delete", "deletecollection", "patch", "update"]
- apiGroups: ["acme.cert-manager.io"]
resources: ["orders"]
verbs: ["delete", "deletecollection"]
If your automation or custom tools relied on these now-restricted permissions, you may need to adjust your workflows or use more granular, specific roles rather than the broad edit role.
Source:
deploy/charts/cert-manager/templates/rbac.yaml(514-529)
โจ Refined ACME Challenge Ownership Model
In this release, we’ve streamlined the ownership model for ACME Challenge resources. Previously, Challenges held an owner reference to both their Order and the parent Issuer. This could lead to ambiguity or unexpected garbage collection behavior in certain edge cases. By removing the owner reference to the Issuer, Challenges are now exclusively owned by their Order, establishing a clearer and more logical hierarchy. This change simplifies the lifecycle management of challenges, ensuring they are properly cleaned up with their associated orders, improving the robustness of the ACME solver.
The pkg/controller/acmeorders/util.go file, responsible for constructing Challenge objects, no longer adds an Issuer or ClusterIssuer as an OwnerReference. Challenges will now only possess an owner reference to the specific Order that created them. This adjustment clarifies that the lifecycle of a Challenge is intrinsically tied to its Order, not the more distant Issuer.
// Old code (removed):
// var (
// issuerGvk = cmapi.SchemeGroupVersion.WithKind("Issuer")
// clusterIssuerGvk = cmapi.SchemeGroupVersion.WithKind("ClusterIssuer")
// )
//
// issuerOwnerRef := metav1.OwnerReference{
// APIVersion: issuerGvk.GroupVersion().String(),
// Kind: issuerGvk.Kind,
// Name: issuer.GetName(),
// UID: issuer.GetUID(),
// BlockOwnerDeletion: ptr.To(true),
// }
//
// if _, ok := issuer.(*cmapi.ClusterIssuer); ok {
// issuerOwnerRef.Kind = clusterIssuerGvk.Kind
// }
//
// OwnerReferences: []metav1.OwnerReference{
// *metav1.NewControllerRef(o, orderGvk),
// issuerOwnerRef, // <-- This line removed
// },
Source:
Minor Updates & Housekeeping
This release also updates the Go toolchain to v1.26.4, refreshes base images to the latest distroless/static-debian12 and base-debian12 versions, and migrates e2e upgrade tests to use Helm OCI registries for chart references, enhancing internal testing robustness.