search

kubernetes-sigs / cluster-api

Home for Cluster API, a subproject of sig-cluster-lifecycle
https://cluster-api.sigs.k8s.io
Apache License 2.0
3.55k stars 1.3k forks source link

Should we increase the default certificate duration to 18 months? #8620

Closed vincepri closed 8 months ago

vincepri commented 1 year ago

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

https://github.com/kubernetes-sigs/cluster-api/blob/299024ffa3a31ee3dce3e1f12d623ea0f8e8824a/util/certs/consts.go#L26

k8s-ci-robot commented 1 year ago

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](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
sbueringer commented 1 year ago

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 commented 1 year ago

/triage accepted

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

sbueringer commented 1 year ago

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 commented 1 year ago

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 https://github.com/kubernetes-sigs/cluster-api/blob/299024ffa3a31ee3dce3e1f12d623ea0f8e8824a/util/certs/types.go#L53

see https://github.com/kubernetes/kubernetes/pull/117791

fabriziopandini commented 9 months ago

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

fabriziopandini commented 9 months ago

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

sbueringer commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 8 months ago

/close

because:

k8s-ci-robot commented 8 months ago

@fabriziopandini: Closing this issue.

In response to [this](https://github.com/kubernetes-sigs/cluster-api/issues/8620#issuecomment-1914525192): >/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](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.