Replies: 1 comment 7 replies
-
|
I've personally validated the steps from the docs, so any deviations from that (such as running Note that the join token only needs to be updated if you change the server CA trust anchor. As long as the root CA for the server CA bundle remains the same, the CA hash in the token will remain the same. This is covered in the CA topology diagrams in the CA rotation docs, and in the token format docs. If you're looking for more hands-on assistance with validating a product built around K3s, you might consider becoming a partner: https://www.suse.com/partners/. As a community project, we're not really staffed to validate products built on top of K3s. The partner team would be able to allocate more resources to work directly with you to validate what you're trying to do. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi Team,
We are currently building a CLI tool to deploy and manage our application on on-premise customer infrastructure, with K3s as our chosen Kubernetes distribution. Since K3s is fully managed by our CLI, we’re extending its capabilities to support certificate rotation through the commands:
mycli certificate rotatemycli certificate rotate-caBelow, I’ve outlined the implementation steps we’ve developed for both leaf certificate rotation and CA certificate rotation (self-signed and custom). We would appreciate your confirmation on whether these are correct, and we also have a few specific questions.
k3s version v1.32.6+k3s1 (eb603ac)
go version go1.23.10
Leaf Certificate Rotation
(Command:
mycli certificate rotate)Steps executed on each node (currently only server nodes; agent nodes will be added soon):
k3s certificate rotatesudo systemctl restart k3sThese steps are repeated on each server node.
Question 1:
Are these steps sufficient for rotating leaf certificates on server nodes? Additionally, can I follow the same process for rotating certificates on agent nodes, or do agent nodes require a different approach?
The official documentation mentions:
systemctl stop k3sk3s certificate rotatesystemctl start k3sCan we safely replace these with a simpler
k3s certificate rotatefollowed bysystemctl restart k3s?CA Certificate Rotation (Self-Signed CA)
(Command:
mycli certificate rotate-ca)We are currently using the default self-signed CA generated by K3s. To rotate it, we follow these steps:
rotate ca certscript from the K3s documentation and store them in a temporary directory.k3s certificate rotate-ca --path <temp_dir>cat <data-dir>/server/node-token, and update all nodes'config.yamlfiles with this token.k3s certificate rotate(Note: This step is not mentioned in the docs, but omitting it caused the cluster to fail during a second CA rotation with trust issues.)
sudo systemctl restart k3sQuestion 2:
Are these the correct and complete steps for rotating self-signed CA certificates?
Question 3:
Regarding the node token:
rotate-caoperation?/var/lib/rancher/k3s/server/node-tokenand/var/lib/rancher/k3s/server/tokenCA Certificate Rotation (Custom CA – Same Root CA)
When rotating a custom CA while keeping the same root CA, our current approach is:
k3s certificate rotate-ca --path <temp_dir>Question 4:
If the root CA itself has changed, what is the correct procedure for rotating the CA certificates?
We attempted the documented approach, but it did not work as expected. Any guidance on the proper steps would be appreciated.
Question 5:
Is it possible to switch between a self-signed CA and a custom CA, and vice versa?
If so, what is the safest and cleanest way to perform such a transition without breaking trust within the cluster?
Thank you for your time and support. We're looking forward to your feedback so we can ensure our CLI tool handles certificate rotation reliably and in alignment with best practices.
Beta Was this translation helpful? Give feedback.
All reactions