Breaking Changes

📋 Recommended Actions ⚠️ Action Required Upgrade to Istio 1.28.2 after carefully reviewing the new minimum Kubernetes version requirement (1.30). Existing Ambient mode users planning nftables migration should be aware of the new safe fallback mechanism. 📝 Summary Istio 1.28.2 delivers crucial updates, enhancing stability and streamlining operations. Critically, the minimum required Kubernetes version has been bumped to 1.30, a change requiring pre-upgrade validation. For Ambient mode, a new intelligent fallback ensures smoother migrations from iptables to nftables, preventing network disruptions by detecting existing artifacts and temporarily sticking to iptables until node reboot. DNS resolution for headless services sees significant improvement, now correctly handling pods with multiple IPs and prioritizing local cluster endpoints for multi-cluster setups. Additionally, a long-standing bug preventing proxy startup when sidecar.istio.io/statsEvictionInterval was 60 seconds or more has been resolved. Updates to the KRT library also improve internal data processing, setting the stage for more robust configurations. Review these changes to ensure a seamless upgrade and optimized mesh. ...

📋 Recommended Actions ⚠️ Action Required Immediate upgrade is strongly recommended to address multiple high-severity security vulnerabilities. Review updates to the vendored ACME client, particularly the deprecation of TLS-SNI-01 and TLS-SNI-02 challenge types, which may impact custom ACME integrations. 📝 Summary cert-manager v1.18.4 lands with vital security fixes and significant ACME protocol updates. This release addresses multiple high-severity CVEs in the underlying Go toolchain and various golang.org/x dependencies, demanding your prompt attention to safeguard your Kubernetes clusters. Beyond security, we’ve refined ACME challenge handling, notably deprecating the insecure TLS-SNI-01 and TLS-SNI-02 challenge types. On the bright side, TLS-ALPN-01 now gracefully supports IP address identifiers, expanding its utility for diverse network configurations. Core components also see a Go version bump and updated distroless base images, boosting overall stability. Upgrade now to secure your certificate management and benefit from improved ACME capabilities. ...

📋 Recommended Actions ⚠️ Action Required ⚠️ Action Required Review your IssuerRef configurations and any external tooling that interacts with cert-manager APIs. The Kubernetes API server no longer injects default kind (‘Issuer’) and group (‘cert-manager.io’) for IssuerRef fields in CRDs. While cert-manager itself handles these internally, external clients might need updates to handle potentially empty kind or group fields. 📝 Summary This release for cert-manager v1.19.1 delivers crucial API consistency and stability improvements, primarily revolving around IssuerReference defaulting. We’ve reverted the behavior where the Kubernetes API server would automatically inject default kind and group values for IssuerRef in CRDs. This means that if you omit these fields, the API server will now store them as empty. While this is an important change for external tooling relying on API server-side defaulting, cert-manager’s internal controllers have been enhanced to seamlessly handle these empty fields at runtime, maintaining expected behavior. We’ve also updated the RequestMatchesSpec logic to prevent unnecessary certificate re-issuances when only default IssuerRef values change. Key dependency updates include sigs.k8s.io/controller-runtime to v0.22.3, github.com/Venafi/vcert/v5 to v5.12.2, and Go to 1.25.3. This update ensures better API predictability and internal stability. Review your workflows, especially if external tools process cert-manager resources and expect API-injected defaults. Immediate action isn’t required for core functionality, but client-side adjustments might be. ...

📋 Recommended Actions ⚠️ Action Required Immediate review of your cert-manager Helm chart deployment is required due to a significant RBAC reversion. Users relying on the ‘disableHTTPChallengesRole’ flag must update their manifests. Review the certificate name constraints fix to ensure correct certificate issuance. 📝 Summary cert-manager v1.18.2 lands with critical updates, most notably a significant reversion of RBAC changes introduced in v1.18.1. This patch release removes the global.rbac.disableHTTPChallengesRole Helm value, consolidating HTTP-01 and DNS-01 challenge-related ClusterRoles into a single, unified controller role. If your deployments relied on disableHTTPChallengesRole to limit permissions, you must immediately review and update your Helm manifests. This reversion effectively means that HTTP-01 challenge permissions, such as creating pods and services, are now always included within the primary challenge controller role, potentially granting broader permissions than you previously configured or intended. Beyond RBAC, this release also delivers a crucial bug fix. It corrects an issue where certificate name constraints for URI domains were being mistakenly interpreted as ExcludedURIDomains instead of PermittedURIDomains in generated Certificate Signing Requests. This fix ensures that your certificates are issued with the exact URI name constraints you specify, preventing unexpected validation failures. Operations engineers should promptly examine their Helm values and RBAC configurations to prevent unintended permission shifts and ensure correct certificate issuance behavior. ...