fix(kubeconfig-rotate): adding rotation of kubeconfig

[jds9090]

Closes #340.

[netlify]

✅ Deploy Preview for kamaji-documentation canceled.

Name	Link
🔨 Latest commit	dcf3a39
🔍 Latest deploy log	https://app.netlify.com/sites/kamaji-documentation/deploys/64ca065124997d00081bdb8c

[prometherion]

Thanks for the quick fix.

I'd like to think about this more in a different way to tackle this. With your proposal change, we need to wait for a TCP reconciliation before having the rotation of the kubeconfig.

Furthermore, we need to have the same logic also for certificates, such as the API server one, or the Front Proxy.

What we could do, my 2 cents, is to leverage the same principle we're suggesting in operating Kamaji, such as deleting the Secret to perform a rotation since this will trigger the TCP reconciliation, thus the Secret creation.

I'm thinking of a Secret controller which is looking up Secret resources and, according to the type, extracts the NotAfter field for the given x509 certificate, and enqueue it back according to the expiration.

Once this has been achieved (with a minimum gap, such as a day) the Controller will take care of deleting it to trigger the TCP reconciliation.

WDYT?

[jds9090]

Thanks for the quick fix.

I'd like to think about this more in a different way to tackle this. With your proposal change, we need to wait for a TCP reconciliation before having the rotation of the kubeconfig.

Furthermore, we need to have the same logic also for certificates, such as the API server one, or the Front Proxy.

What we could do, my 2 cents, is to leverage the same principle we're suggesting in operating Kamaji, such as deleting the Secret to perform a rotation since this will trigger the TCP reconciliation, thus the Secret creation.

I'm thinking of a Secret controller which is looking up Secret resources and, according to the type, extracts the NotAfter field for the given x509 certificate, and enqueue it back according to the expiration.

Once this has been achieved (with a minimum gap, such as a day) the Controller will take care of deleting it to trigger the TCP reconciliation.

WDYT?

Yes, That was also my second consideration. I want to give you another option and you can decide which one is nicer for kamaji.

In terms of the kubeadm control plane provider, it uses the sync-period option(https://github.com/kubernetes-sigs/cluster-api/blob/1f5fcd22fceccdd6286914bfb0ac494639f4d000/controlplane/kubeadm/main.go#L137) and they provide users certificatesExpiryDays(https://cluster-api.sigs.k8s.io/tasks/certs/auto-rotate-certificates-in-kcp.html).

Like kubeadm control plane provider, we can add the sync-period option for TCPs' reconciliation and modify the checkCertificateValidity function(

kamaji/internal/crypto/crypto.go

Line 196 in 8e8ee92

func checkCertificateValidity(cert x509.Certificate) bool {

) to check if certificates are going to expire in advance (ref. https://github.com/kubernetes-sigs/cluster-api/blob/1f5fcd22fceccdd6286914bfb0ac494639f4d000/util/collections/machine_filters.go#L187).

[jds9090]

I think TCPs should be reconciled regularly with two reasons and we can check the validity of the certificates before expiration on the regular basis.

Please, refer https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager.

A period sync happens for two reasons:

1. To insure against a bug in the controller that causes an object to not be requeued, when it otherwise should be requeued.
2. To insure against an unknown bug in controller-runtime, or its dependencies, that causes an object to not be requeued, when it otherwise should be requeued, or to be removed from the queue, when it otherwise should not be removed.

[prometherion]

Closed in favour of #342.