Skip to main content
Talos Linux automatically manages and rotates all server side certificates for etcd, Kubernetes, and the Talos API. Note however that the kubelet needs to be restarted at least once a year in order for the certificates to be rotated. Any upgrade/reboot of the node will suffice for this effect. You can check the Kubernetes certificates with the command talosctl get KubernetesDynamicCerts -o yaml on the controlplane. Client certificates (talosconfig and kubeconfig) are the user’s responsibility. Each time you download the kubeconfig file from a Talos Linux cluster, the client certificate is regenerated giving you a kubeconfig which is valid for a year. The talosconfig file should be renewed at least once a year, using the talosctl config new command, as shown below, or by one of the other methods.

​
Generating new client configuration

A new talosconfig can be generated in three ways: from a control plane node, from a secrets bundle, or from the control plane machine configuration.

​
Using control plane node

If you have a valid (not expired) talosconfig with os:admin role, a new client configuration file can be generated with talosctl config new against any controlplane node:
A specific role and certificate lifetime can be specified.

​
From secrets bundle

If a secrets bundle (secrets.yaml from talosctl gen secrets) was saved while generating machine configuration:
Note: <cluster-name> and <cluster-endpoint> arguments don’t matter, as they are not used for talosconfig.

​
From control plane machine configuration

The control plane machine configuration holds the root Talos API CA, so a new talosconfig can be generated from it. First, extract a secrets bundle from the control plane configuration:
Then generate the talosconfig from the secrets bundle, as in From secrets bundle:
The generated talosconfig has no endpoints. Set the endpoints to your control plane nodes:
The secrets bundle holds every secret of the cluster. Store it securely, or delete it once the talosconfig is generated.