Increase certificate validity

[vrutkovs]

installer/pkg/asset/tls/tls.go

Line 29 in 44b2220

ValidityThirtyMinutes = time.Minute * 30

Cert validity is hardcoded to 30 mins. In most BYOR cases this is insufficient, as bootstrap and masters need to be prepared first (setup CRIO, pull images etc.) and by the time kubelets issue CSR the cert might expire.

As a temporary measure it would be nice to have this period extended to an hour, but ideally this should be configurable

[wking]

As a temporary measure it would be nice to have this period extended to an hour, but ideally this should be configurable

I'm fine bumping this to an hour, but I'd rather not make it configurable. Folks who need to override the default should be able to adjust by clobbering the cert (or any TLS assets they like) in the asset directory during a multi-step install. I dunno if that works at the moment, but it will with #556 or similar.

[wking]

Cross linking #167. This issue is about making expiration less likely. #167 issue is about handling expiration when it happens.

[vrutkovs]

adjust by clobbering the cert (or any TLS assets they like) in the asset directory

So that'd require some sort of 'regen certs' util?

[vrutkovs]

It seems a proper rotation (if #167 is about that) would fix that, without adjustments to the validity time. Feel free to close this issue if that's the case

[wking]

adjust by clobbering the cert (or any TLS assets they like) in the asset directory

So that'd require some sort of 'regen certs' util?

Well, the caller could generate the clobbering certs however they liked (e.g. with openssl req ... similar to this). Then the installer would pick up the override on the next asset re-rendering step and incorperate the clobbered cert in downstream assets like the kubelet's kubeconfig.

It seems a proper rotation (if #167 is about that) would fix that...

Kubernetes is supposed to handle kubelet cert rotation for us. #167 is about "what if all of my signers were offline for long enough for my certs to expire?". That's a lot more difficult to deal with than this issue's "let's make it easier to avoid having a kubelet cert expire in the first place".

Also note that any changes we make to the kubelet cert here are going to get thrown out when the kubelet rotates its cert for the first time. From the docs, that rotation happens "[a]s the expiration of the signed certificate approaches". Folks who expect to bump into this issue by pausing their whole cluster for long periods of time should configure their certificate rotation to make it unlikely that a whole-cluster-offline period is smaller than their certificate expirations