Allow immediate renewal of certs if requested.

[SpectralHiss]

This requests stems from a situation where a Venafi TPP issuer went offline temporarily due to a hardware failure.
On the issuance side the failures resulted in a few timeouts temporarily.
As the backend issuer went back online the cert renewal didn't happen immediately.
We suspected this was just due to normal backoff on retries so a kubectl cert-manager renew was attempted to immediately renew.

To our surprise this still didn't renew the certificate.

Looking at the cert-manager controller logs we saw messages like so:
cert-manager/controller/certificates-trigger "msg"="Not re-issuing certificate as an attempt has been made in the last hour" "key"="istio-system/test-cert" "retry_delay"=3599178696277

Therefore we assumed from that log that the rate limit avoidance designed to protect ACME servers blocked us.
This is a good default that perhaps we'd like to be able to override in some cases.

This wasn't crucial as waiting 1 hour would solve the issue, in most cases one can wait without much issue.
It would make for a nicer UX and ease of operations if one has the option to force an immediate renewal.

Describe the solution you'd like

If there is a way to mark the certificate for immediate renewal (ignoring the rate limiting prevention measure) , we'd like to be able to use it.

@JoshVanL suggested adding a --force flag on the kubectl cert-manager renew command for this use case which i think is an adequate solution.

Another more complicated, nice to have general alternative is to have the rate limiting behaviour somehow controlled in the issuer, it would depend on the various backend issuers, for example Vault allows custom api quotas configuration, which we could have a similar config for.
We'd probably still want the force flag anyways in some edge cases even with above configuration.

Environment details:

• Kubernetes version:
  GKE 1.20.9
• cert-manager version:
  1.5.4

/kind feature

[munnerz]

Hm, the way that the cmctl renew command works is that it bypasses the trigger controller by directly adding the Issuing condition to the Certificate resource.

Are you sure that this was actually the most up to date reconciliation of the certificate controllers? That error message shouldn't be an issue when using cmctl renew.

[SpectralHiss]

ah interesting, at the time i was using the regular plugin v1.5.4 (so using kubectl cert-manager renew cert ) has the logic changed since then?

For some people they like not even have to use the cli at all in which case having a per issuer rate limiting config would be nice but this was not really a high-priority issue at all, just a nice-to-have.

[irbekrm]

It is possible that it was this issue #4642

If the bug linked above would have been hit then the first renewal would have resulted in successful CertificateRequests, but only the second renewal (i.e after 1 hour backoff) would have resulted in the new TLS certs synced to Secrets and the Certificates statuses updated.

[jetstack-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle stale

[jetstack-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle rotten
/remove-lifecycle stale

[irbekrm]

cmctl renew does renew immediately (without the 1 hour backoff)

I think the issue here may have been #4642 that was fixed in cert-manager 1.7

Do let us know if that is still an issue.