-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Certificate and access management for edge computing #2342
Comments
Support for Basic authentication has been removed from upstream Kubernetes. Note that this is not just deprecated or disabled, but deleted from the codebase: kubernetes/kubernetes#89069 K3s has retained some basic auth code in the interim, but it is only used for bootstrapping new cluster members. In the future this will probably go away in favor of token auth or something else more in line with upstream. |
Ok, good to know that the basic auth has been removed. As the token auth (or any equivalent) may not be ready soon, is there a way or a setting to increase the period of validity of the X509 certificates created during the k3s setup? We already had some practical cases where edge servers have been running more than 10 years on field (yes it's possible) with theirs certificates expired, this isn't a good situation. |
You have servers that have been up without a reboot or service restart for 10 years? All you have to do is schedule a periodic restart of the k3s service and the certs will get updated. Keep in mind that upstream Kubernetes itself has a much shorter support lifecycle so you're really pushing things with more than a couple years. If you want to generate an admin client certificate that is valid for longer than the stock one, you can do so using the cert and key at For example, the default admin certificate has a subject of |
Running for 10 years, yes, but with reboots of course! I understand that if we want to keep k3s running, we need to restart the k3s service like every week or month, so all the generated certificates will be renewed. The problem is the admin certificate with 1 year validity, I guess it will be renewed but we have to get each time the new one. The best option seems to be creating a new admin certificate, like you recommend, with a longer validity. I have seen some examples here #684 on how to sign the new certificate and you gave me the information about the values to put in the subject (but I think I can copy the subject of the default admin certificate to get the same rights). |
Small bump here, just to know if there is way to push the expiration date of all certificates issued when k3s is installed. This will solve all the issue (no need to restart k3s, no need to issue a new admin cert). |
I was able to get an admin certificate valid 10 years using these commands:
A CSR is extracted from the current admin certificate and used for creating a new certificate signed by the CA with a 10 years validity. Also the private key and the CA certificate for the API server are printed, these are needed for a remote connection. But I'm asking again, if a setting could exist to make all the certificates created during the installation valid for 10 years, that would be great and solved all theses certificate issues. |
This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label) for 180 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the bot will automatically close the issue in 14 days. Thank you for your contributions. |
Thank you, @sraillard . your comment was extremely helpful after I ran into this on my 1-year-old cluster. k3s set the default client cert for root to expire after a year or so. This leads to a problem where you can't administer your own cluster because your root account's cert is expired. There's nothing as frustrating as being locked out of your own server. So I had to figure out how to fix this. How to manually renew k3s certs.
Once you find the expired certs (they will be ones which expire one year after you set up your cluster), here is the script I ran:
you can use this process to update the client cert for /root/.kube/config as follows:
Note that etcd/client.crt actually uses its own Finally, (Note that replacing only the client-admin cert as in sraillard's post will allow basic |
Most of this has already been validated per @mdrahman-suse. When he returns from PTO he can update the status and steps for individual scenarios. One more scenario being tested now by @est-suse. |
The validation of this feature is completed as per the scope below but not limited to, will continue running additional as per of validating #7081
|
Is your feature request related to a problem? Please describe.
Certificate CA is issued for 10 years and others certificates are issued for 1 year.
When the k3s server is restarted, these certificates are renewed if their validity is under 90 days.
In edge computing, you may have single node that you don't want to reboot and if you deploy a lot of nodes, you may not want to reboot them at regular interval to renew the certificates if there are working fine.
Describe the solution you'd like
For this kind of nodes, is-it possible to change the default validity period for each of the certificates issued (CA and other certificate)? In that case, we can choose a less risky interval than 1 year.
Describe alternatives you've considered
For remote scripting using the API server, if the admin certificate is expired (after one year), we'll not be able to interact with k3s API server. Even if the k3s server is restarted and certificates are renewed, we'll need to copy from the k3s server the new admin certificate. In version prior to 1.19, the admin user had a password and not a certificate to authenticate. Will it be possible to add an option during installation so we can set an admin password? Then we can use again the password authentication (that will never expires) instead of certificate.
Additional context
I have tried to add this line:
at the end of the file
/var/lib/rancher/k3s/server/cred/passwd
and then restart the k3s server, but it doesn't seem to work.The text was updated successfully, but these errors were encountered: