Skip to content

feature request: Add custom renewal time for certificates #437

@transfaeries

Description

@transfaeries

It'd be useful to give people more control over when certificates renew rather than a constant 30 days before expiry. Shorter times would be useful for testing, and in general people or companies could choose a different interval to match their own schedule.

At the moment the time to renewal is set as a constant in pkg/controller/certificates/sync.go

const renewBefore = time.Hour * 24 * 30

It subtracts this number from the expiry date and renews if the result is less than 0

durationUntilExpiry := cert.NotAfter.Sub(time.Now())
renewIn := durationUntilExpiry - renewBefore
if renewIn <= 0 {
	err := c.renew(ctx, i, crtCopy)
	...
 }

I propose that the user should be allowed to provide their own renewIn as an annotation on the ingress or a field in the certificate issue. In the form of a string "00d00h00m".

The tricky thing is, since as of now the code relies on a fixed timestamp on the certificate to count down the hours until renewal. A variable renewal time would have to be stored somewhere. Possibly as a field on the certificate resource.

Basically the program would take this string, convert it into a duration, subtract that duration from the expiry date, and store this as a renewBefore. So for instance if the user provides 15d00h00m. For a certificate that expires in 90 days renewBefore should be set to
90 days - 15 days = 75 days. So we'd store 75*time.Hour*24 + 0*time.Hour + 0*time.Minute or as a string 75d00h00m

So then every time the controller checks if it should renew instead of subtracting the constant time.Hour * 24 * 30 it would get the custom duration and subtract that.

I've started writing some of this code, but I'm having trouble figuring out a) how to read from an annotation and pass it onto pkg/controller/certificates/sync.go b) how to read and write from the certificate resource for pkg/controller/certificates/sync.go

I also wonder if other people might not have a better way to do this. This is just what I figured would be one way to do it that leaves most of the existing code untouched.

/kind feature

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/featureCategorizes issue or PR as related to a new feature.lifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions