Skip to content

Conversation

@inteon
Copy link
Member

@inteon inteon commented Oct 10, 2025

This should prevent the unexpected renewals after upgrading to 1.19.x (see #8158).

How to test:

  1. install cert-manager 1.18.2 and create a certificate
  2. upgrade to cert-manager 1.19.0 (keep the CRDs @ 1.18.2)
  3. upgrade the CRDs to 1.19.0 (start with Certificate CRD)

Kind

/kind bug

Release Note

BUGFIX: in case kind or group in the issuerRef of a Certificate was omitted, upgrading to 1.19.x incorrectly caused the certificate to be renewed

CyberArk tracker: VC-46054

…ting mismatches when upgrading

Signed-off-by: Tim Ramlot <42113979+inteon@users.noreply.github.com>
@cert-manager-prow cert-manager-prow bot added kind/bug Categorizes issue or PR as related to a bug. release-note Denotes a PR that will be considered when it comes time to generate release notes. dco-signoff: yes Indicates that all commits in the pull request have the valid DCO sign-off message. labels Oct 10, 2025
@inteon inteon requested a review from erikgb October 10, 2025 10:28
@cert-manager-prow cert-manager-prow bot added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label Oct 10, 2025
Copy link
Member

@erikgb erikgb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you checked if this fixes #8158, @inteon?

/approve

@cert-manager-prow cert-manager-prow bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 10, 2025
@inteon
Copy link
Member Author

inteon commented Oct 10, 2025

Have you checked if this fixes #8158, @inteon?

/approve

No, I have not had the time yet, could you verify?

@erikgb
Copy link
Member

erikgb commented Oct 10, 2025

Have you checked if this fixes #8158, @inteon?
/approve

No, I have not had the time yet, could you verify?

I have no idea on how to install/upgrade to a c-m version from a feature branch.

@erikgb erikgb requested a review from Copilot October 12, 2025 09:36
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR fixes a bug where cert-manager 1.19.x incorrectly renewed certificates during upgrades when the issuerRef's kind or group fields were omitted in the original Certificate. The fix replaces a simple reflect.DeepEqual comparison with custom logic that handles default values for issuerRef fields.

  • Replaces reflect.DeepEqual with explicit field-by-field comparison for IssuerRef
  • Adds helper functions to handle default values for issuer kind and group fields
  • Removes unused reflect import

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

Copy link
Member

@erikgb erikgb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @inteon! Even if this issue doesn't fully resolve #8158, I think it's a good change. I also think we should cherry-pick this to the release-1.19 branch. Adding a hold in case you want to implement the suggestion from Copilot.

/lgtm
/approve
/hold
/cherry-pick release-1.19

@cert-manager-prow cert-manager-prow bot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. lgtm Indicates that a PR is ready to be merged. labels Oct 12, 2025
@maelvls maelvls added the cybr Used by CyberArk-employed maintainers to report to line management what's being worked on. label Oct 14, 2025
@maelvls
Copy link
Member

maelvls commented Oct 14, 2025

We plan on merging this fix before releasing v1.19.1, and backport it to v1.18.3. @wallrj proposed to work on this.

@cert-manager-prow cert-manager-prow bot added dco-signoff: no Indicates that at least one commit in this pull request is missing the DCO sign-off message. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed lgtm Indicates that a PR is ready to be merged. dco-signoff: yes Indicates that all commits in the pull request have the valid DCO sign-off message. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Oct 14, 2025
@cert-manager-prow cert-manager-prow bot added dco-signoff: yes Indicates that all commits in the pull request have the valid DCO sign-off message. and removed dco-signoff: no Indicates that at least one commit in this pull request is missing the DCO sign-off message. labels Oct 14, 2025
@wallrj-cyberark
Copy link
Member

I've pushed the following changes to Tim's branch:

  • added some unit-tests
  • added explanatory comments.
  • documented the new default constants and used the same sources as are used in the CertificateRequest controller.
- Add TestRequestMatchesSpecIssuerRef covering name, kind, and group
- Include cases for defaulted Kind/Group vs empty fields in CRs
- Treat empty Kind/Group in CertificateRequest as 'Issuer' and
- 'cert-manager.io' to avoid re-issuing certificates after 1.19

Signed-off-by: Richard Wall <richard.wall@cyberark.com>
@wallrj-cyberark
Copy link
Member

We plan on merging this fix before releasing v1.19.1, and backport it to v1.18.3. @wallrj proposed to work on this.

This PR alone doesn't fix the problem. We think the original problem occurs when user upgrade to the 1.19 CRDs before upgrading the cert-manager controller causing the still running 1.18 controller to re-establish API watches and end up with inconsistent caches, where the cache contains Certificates that have the new API defaults, but CertificateRequests which have not yet been refreshed and do not have the new defaults.

@erikgb
Copy link
Member

erikgb commented Oct 14, 2025

We plan on merging this fix before releasing v1.19.1, and backport it to v1.18.3. @wallrj proposed to work on this.

This PR alone doesn't fix the problem. We think the original problem occurs when user upgrade to the 1.19 CRDs before upgrading the cert-manager controller causing the still running 1.18 controller to re-establish API watches and end up with inconsistent caches, where the cache contains Certificates that have the new API defaults, but CertificateRequests which have not yet been refreshed and do not have the new defaults.

I agree, but this PR will allow us to reintroduce the API defaults in a future release - if we want. I have created a PR to revert the problematic API defaults, #8173, and think we should merge both PRs and cherry-pick them to the 1.19 release branch. This PR can even be cherry-picked to the 1.18 release branch, as I think it also fixes a bug unrelated to the API defaulting problem.

})
}
}

Copy link
Member

@wallrj-cyberark wallrj-cyberark Oct 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I cherry picked these new tests on top of #8173 and ran them to demonstrate the problem. Here's the output:

-*- mode: compilation; default-directory: "~/projects/cert-manager/cert-manager/pkg/util/pki/" -*-
Compilation started at Wed Oct 15 09:47:25

go test -run='TestRequestMatchesSpecIssuerRef$' 
--- FAIL: TestRequestMatchesSpecIssuerRef (0.69s)
    --- FAIL: TestRequestMatchesSpecIssuerRef/should_not_report_any_violation_if_Certificate_issuerRef_Kind_and_Group_are_defaulted_and_CertificateRequest's_are_empty (0.00s)
        match_test.go:477: 
            	Error Trace:	/home/richard/projects/cert-manager/cert-manager/pkg/util/pki/match_test.go:477
            	Error:      	Not equal: 
            	            	expected: []string(nil)
            	            	actual  : []string{"spec.issuerRef"}
            	            	
            	            	Diff:
            	            	--- Expected
            	            	+++ Actual
            	            	@@ -1,2 +1,4 @@
            	            	-([]string) <nil>
            	            	+([]string) (len=1) {
            	            	+ (string) (len=14) "spec.issuerRef"
            	            	+}
            	            	 
            	Test:       	TestRequestMatchesSpecIssuerRef/should_not_report_any_violation_if_Certificate_issuerRef_Kind_and_Group_are_defaulted_and_CertificateRequest's_are_empty
    --- FAIL: TestRequestMatchesSpecIssuerRef/should_not_report_any_violation_if_Certificate_issuerRef_Kind_and_Group_are_defaulted_and_CertificateRequest_issuerRef_Group_is_empty (0.00s)
        match_test.go:477: 
            	Error Trace:	/home/richard/projects/cert-manager/cert-manager/pkg/util/pki/match_test.go:477
            	Error:      	Not equal: 
            	            	expected: []string(nil)
            	            	actual  : []string{"spec.issuerRef"}
            	            	
            	            	Diff:
            	            	--- Expected
            	            	+++ Actual
            	            	@@ -1,2 +1,4 @@
            	            	-([]string) <nil>
            	            	+([]string) (len=1) {
            	            	+ (string) (len=14) "spec.issuerRef"
            	            	+}
            	            	 
            	Test:       	TestRequestMatchesSpecIssuerRef/should_not_report_any_violation_if_Certificate_issuerRef_Kind_and_Group_are_defaulted_and_CertificateRequest_issuerRef_Group_is_empty
    --- FAIL: TestRequestMatchesSpecIssuerRef/should_not_report_any_violation_if_Certificate_issuerRef_Kind_and_Group_are_defaulted_and_CertificateRequest_issuerRef_Kind_is_empty (0.00s)
        match_test.go:477: 
            	Error Trace:	/home/richard/projects/cert-manager/cert-manager/pkg/util/pki/match_test.go:477
            	Error:      	Not equal: 
            	            	expected: []string(nil)
            	            	actual  : []string{"spec.issuerRef"}
            	            	
            	            	Diff:
            	            	--- Expected
            	            	+++ Actual
            	            	@@ -1,2 +1,4 @@
            	            	-([]string) <nil>
            	            	+([]string) (len=1) {
            	            	+ (string) (len=14) "spec.issuerRef"
            	            	+}
            	            	 
            	Test:       	TestRequestMatchesSpecIssuerRef/should_not_report_any_violation_if_Certificate_issuerRef_Kind_and_Group_are_defaulted_and_CertificateRequest_issuerRef_Kind_is_empty
FAIL
exit status 1
FAIL	github.com/cert-manager/cert-manager/pkg/util/pki	0.745s

Compilation exited abnormally with code 1 at Wed Oct 15 09:47:27, duration 2.48 s

// These defaults are also applied at runtime by the cert-manager
// CertificateRequest controller.
//
// TODO(wallrj): Move this runtime defaulting to `internal/apis/certmanager/v1/defaults.go`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@erikgb Removed TODO comment as agreed during standup. I made my point. And we hope that in future the API defaults will be used. Not runtime defaults.

//
// ... to the API struct.
//
// TODO(wallrj): Set the issuerRef defaults here too.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed TODO comment as agreed during standup. I made my point. And we hope that in future the API defaults will be used. Not runtime defaults.

@wallrj wallrj requested a review from Copilot October 15, 2025 09:59
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.


Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

…esSpec

- Explain that IssuerRef comparisons ignore default group and kind
- Describe upgrades where CRD defaults can cause transient mismatches
- Document issuerKindsEqual and issuerGroupsEqual behavior
- Update test comment to describe the equivalence rationale

Signed-off-by: Richard Wall <richard.wall@cyberark.com>
Copy link
Member

@erikgb erikgb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

Thanks for picking this up, @wallrj! And for the initial work, @inteon! 🚀

We should attempt an automated cherry-pick of this to a supported release branches.

@cert-manager-prow cert-manager-prow bot added the lgtm Indicates that a PR is ready to be merged. label Oct 15, 2025
@cert-manager-prow
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: erikgb

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@wallrj-cyberark
Copy link
Member

Thanks @erikgb

/unhold
/cherry-pick release-1.18
/cherry-pick release-1.19

@cert-manager-bot
Copy link
Contributor

@wallrj-cyberark: once the present PR merges, I will cherry-pick it on top of release-1.18, release-1.19 in new PRs and assign them to you.

In response to this:

Thanks @erikgb

/unhold
/cherry-pick release-1.18
/cherry-pick release-1.19

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@cert-manager-prow cert-manager-prow bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 15, 2025
@cert-manager-prow cert-manager-prow bot merged commit 1514131 into cert-manager:master Oct 15, 2025
6 checks passed
@cert-manager-bot
Copy link
Contributor

@wallrj-cyberark: new pull request created: #8174

In response to this:

Thanks @erikgb

/unhold
/cherry-pick release-1.18
/cherry-pick release-1.19

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@cert-manager-bot
Copy link
Contributor

@wallrj-cyberark: new pull request created: #8175

In response to this:

Thanks @erikgb

/unhold
/cherry-pick release-1.18
/cherry-pick release-1.19

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. cybr Used by CyberArk-employed maintainers to report to line management what's being worked on. dco-signoff: yes Indicates that all commits in the pull request have the valid DCO sign-off message. kind/bug Categorizes issue or PR as related to a bug. lgtm Indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

6 participants