Certificates: preventing CertificateRequest creation runaway#5567
Certificates: preventing CertificateRequest creation runaway#5567JoshVanL wants to merge 20 commits intocert-manager:masterfrom
Conversation
|
Implementation is still not quite right.. we shouldn't fail on a duplicate secret name, and instead just block on the issuance. Triggering a new issuance on a non-failed Certificate which no longer has a duplicate secret name should happen right away, so the e2e tests are correctly failing. |
pkg/controller/certificates/duplicatesecrets/duplicatesecrets_controller.go
Outdated
Show resolved
Hide resolved
pkg/controller/certificates/duplicatesecrets/duplicatesecrets_controller.go
Outdated
Show resolved
Hide resolved
|
|
||
| // If the Certificate has a duplicate Secret name condition set, we should | ||
| // fail the issuance. If we discover that we have a duplicate Secret name set | ||
| // ourselves, we exit early and wait for that condition to be set. |
|
This won't make 1.11. I was asked to take a look at this but haven't had a chance. Pushing to 1.12! |
|
Looking forward to this feature. We already faced the "certificate secret race" multiple times. Issued about 40'000 certificates from our on-premise ACME server. |
|
Hi @JoshVanL! Just to let you know, we will have a code freeze for 1.12 starting Wed 19 April 2023. The code freeze will be waived after the release of 1.12 on Wed 26 April 2023. |
3cfd601 to
d00373a
Compare
9465bb8 to
ca0e839
Compare
|
/retest |
dc4a643 to
6e5f587
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Why does this need a controller? We can check if secret's ownerReference matches the certificates resource ID |
eecf685 to
4fc6a8f
Compare
ownerReferences can be disabled (and probably should be in a production environment): https://cert-manager.io/docs/installation/upgrading/#reinstalling-cert-manager |
Signed-off-by: Tim Ramlot <42113979+inteon@users.noreply.github.com>
Signed-off-by: Tim Ramlot <42113979+inteon@users.noreply.github.com>
Signed-off-by: Tim Ramlot <42113979+inteon@users.noreply.github.com>
Signed-off-by: Tim Ramlot <42113979+inteon@users.noreply.github.com>
Signed-off-by: Tim Ramlot <42113979+inteon@users.noreply.github.com>
dc7371f to
8320cc7
Compare
…ecretName conflict Signed-off-by: Tim Ramlot <42113979+inteon@users.noreply.github.com>
8320cc7 to
b90e20b
Compare
Signed-off-by: Tim Ramlot <42113979+inteon@users.noreply.github.com>
|
I updated the PR:
The new behavior looks as follows: This is the script I used to generate the certs |
fc85050 to
28e298b
Compare
Signed-off-by: Tim Ramlot <42113979+inteon@users.noreply.github.com>
| condition := buildInConflictCondition(duplicates) | ||
| crt = crt.DeepCopy() | ||
| if condition != nil { | ||
| apiutil.SetCertificateCondition(crt, crt.Generation, condition.Type, condition.Status, condition.Reason, condition.Message) |
There was a problem hiding this comment.
Note: In api-conventions.md, the reason field is described as "a one-word CamelCase reason for the condition's last transition"
There was a problem hiding this comment.
Thanks, currently, the reason is used to store what certs are in conflict & this value is actually used by the controller.
As discussed in today's standup, we probably can implement a solution that does not require this.
Signed-off-by: Tim Ramlot <42113979+inteon@users.noreply.github.com>
2316af9 to
132a779
Compare
Signed-off-by: Tim Ramlot <42113979+inteon@users.noreply.github.com>
f726d2c to
c5155a1
Compare
|
NOTE: the current implementation makes all conflicting certificates not ready. everything breaks (current master) |
|
fixed in #6406 |
Fixes #4846
PR adds a new Condition type to Certificates
DuplicateSecretName. This condition is managed by a newDuplicateSecretNamecontroller, and sets this condition on Certificates which have the samespec.secretNameas that as another Certificate in the same Namespace. This condition blocks issuance./kind feature
/milestone v1.11
You can check that this PR works by installing the below manifests, and view it is currently broken on master but fixed with this PR.