|
|
|
@ -70,14 +70,20 @@ clients using tokens signed by the old key have received new tokens.
|
|
|
|
|
## Decision |
|
|
|
|
|
|
|
|
|
* K3s will allow for use of CA certificates signed by an arbitrary set of external root/intermediate CAs. |
|
|
|
|
* K3s will allow for nondisruptive renewal or replacement of the CA certificates and keys, if the cluster was |
|
|
|
|
* K3s will allow for non-disruptive[^1] renewal or replacement of the CA certificates and keys, if the cluster was |
|
|
|
|
originally started using user-provided certificates signed by an external CA. |
|
|
|
|
* K3s will allow for disruptive renewal or replacement of cluster CA certificates and keys, if the cluster was |
|
|
|
|
* K3s will allow for disruptive[^2] renewal or replacement of cluster CA certificates and keys, if the cluster was |
|
|
|
|
originally started with autogenerated self-signed CAs. |
|
|
|
|
* K3s will provide example tooling to allow users to generate cluster CA certificates and keys prior to initial |
|
|
|
|
cluster startup, and provide tooling and process documentation to update the bootstrap data and prepare agents |
|
|
|
|
to trust the new certificates (if necessary) |
|
|
|
|
|
|
|
|
|
[^1]: Non-disruptive renewal requires no change to node configuration. The service only needs to be restarted. |
|
|
|
|
[^2]: Disruptive renewal requires changes to the K3s CLI flags, configuration file, or environment variables |
|
|
|
|
prior to restarting the service. Additionally, the cluster may experience a temporary outage while the |
|
|
|
|
configuration change has been affected to all nodes, due to cluster nodes temporary not sharing a common |
|
|
|
|
root of trust. |
|
|
|
|
|
|
|
|
|
## Consequences |
|
|
|
|
|
|
|
|
|
This will require additional documentation, CLI subcommands, and QA work to validate the process steps. |
|
|
|
|