Should we increase the default certificate duration to 18 months?

[vincepri]

We currently create cluster certificate that last 1 year, with the current upstream efforts to increase the support skew kubernetes/enhancements#3936, should we change the default certificate duration to allow more time for folks to upgrade their nodes?

cluster-api/util/certs/consts.go

Line 26 in 299024f

DefaultCertDuration = time.Hour * 24 * 365

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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/test-infra repository.

[sbueringer]

If I see correctly this duration is only used by KCP to generate the kubeconfig secret. Today we generate it with 1 year expiry and then regenerate it after 6 months.

I'm not sure how this is related with the support skew KEP.

If I understand your intent correctly we should probably open this issue for kubeadm instead so the hard-coded 1 year expiry that kubeadm uses (and we just inherit) is extended. This would give us a longer expiry of the certificates on machines and thus we can keep them around for longer.

[fabriziopandini]

/triage accepted

Agree with @sbueringer, just adding that with automatic certificate rotation recently implemented also kubeadm expiration is not a big problem anymore

[sbueringer]

Adding on top of that. With the current default setup (core CAPI + KCP + CABPK) we only rotate control plane machines. Worker machines don't have to be rotated as they use a self-signed server certificate that is never validated (client certificate is rotated automatically).

As the skew KEP would allow us to only keep worker nodes longer extending the expiry in kubeadm is not necessary.

[neolit123]

note that if this is an RSA cert paired with a 2048 key, expiration > 1 year would need a bigger key. e.g. 3072.

see
https://kubernetes.slack.com/archives/C019LFTGNQ3/p1683275607359709?thread_ts=1683235193.545829&cid=C019LFTGNQ3

---

off topic

cert serials must be in the 1,max range

cluster-api/util/certs/types.go

Line 53 in 299024f

serial, err := rand.Int(rand.Reader, new(big.Int).SetInt64(math.MaxInt64))

see
kubernetes/kubernetes#117791

[fabriziopandini]

I'm leaning towards closing here, giving that cert duration is driven by kubeadm and in CAPI we now have automatic certificate renewal

[fabriziopandini]

@sbueringer @vincepri
opinions
(if not, we should probably move the issue to kubeadm)

[sbueringer]

Agree, if there is still interest in seeing this implemented we need a change in kubeadm first (and thus we need an issue over there)

[Levi080513]

Can we support configuration of DefaultCertDuration?
Users may use the kubeconfig generated by CAPI as the basis for the upper-layer management system to access the workload cluster. The current default validity period seems a bit short.

[sbueringer]

I think the scope of this issue is the certificates on the Machines, not the kubeconfig we generate.
(otherwise "should we change the default certificate duration to allow more time for folks to upgrade their nodes?" wouldn't make sense)

[fabriziopandini]

Users may use the kubeconfig generated by CAPI as the basis for the upper-layer management system to access the workload cluster.

I would advise avoiding to re-use the kubeconfig generated by CAPI for other services (or for users).
Instead, you should create a new certificate, with a dedicated identity, and scope it down it permission to what is strictly required.

[Levi080513]

I think the scope of this issue is the certificates on the Machines, not the kubeconfig we generate. (otherwise "should we change the default certificate duration to allow more time for folks to upgrade their nodes?" wouldn't make sense)

Yes, sorry for responding to other questions.

[Levi080513]

Users may use the kubeconfig generated by CAPI as the basis for the upper-layer management system to access the workload cluster.

I would advise avoiding to re-use the kubeconfig generated by CAPI for other services (or for users). Instead, you should create a new certificate, with a dedicated identity, and scope it down it permission to what is strictly required.

Thanks for the reply, this is very helpful to me.

[fabriziopandini]

/close

because:

• changing cert duration requires changes in kubeadm first, starting by increasing key length
• we answered to question about the cert in the generated kubeconfig file

[k8s-ci-robot]

@fabriziopandini: Closing this issue.

In response to this:

/close

because:

• changing cert duration requires changes in kubeadm first, starting by increasing key length
• we answered to question about the cert in the generated kubeconfig file

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/test-infra repository.