Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 17 additions & 22 deletions public/talos/v1.15/security/cert-management.mdx
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
---
title: "How to manage PKI and certificate lifetimes with Talos Linux"

Check warning on line 2 in public/talos/v1.15/security/cert-management.mdx

View workflow job for this annotation

GitHub Actions / docs-checks

title/title-case

page title should be title case; capitalize "manage" (or add it to exceptions.txt if it's a proper noun)
description: Manage certificate lifetimes and regenerate client credentials in a Talos cluster.
aliases:
- ../../guides/managing-pki
Expand All @@ -24,6 +24,8 @@

## 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,
Expand All @@ -49,33 +51,26 @@

### From control plane machine configuration

In order to create a new key pair for client configuration, you will need the root Talos API CA.
The base64 encoded CA can be found in the control plane node's configuration file.
Save the CA public key, and CA private key as `ca.crt`, and `ca.key` respectively:
The control plane machine configuration holds the root Talos API CA, so a new `talosconfig` can be generated from it.

```shell
yq eval .machine.ca.crt controlplane.yaml | base64 -d > ca.crt
yq eval .machine.ca.key controlplane.yaml | base64 -d > ca.key
First, extract a secrets bundle from the control plane configuration:

Check notice on line 57 in public/talos/v1.15/security/cert-management.mdx

View workflow job for this annotation

GitHub Actions / doc-accuracy

Doc accuracy — NOTICE

talosctl gen refuses to overwrite an existing secrets.yaml or talosconfig, which readers in the original cluster directory will hit. Why: Upstream validateFileExists returns "file already exists, use --force to overwrite" unless -f is passed, so a reader renewing an expired talosconfig in the directory that already holds secrets.yaml or talosconfig will see an unexplained error mid-procedure. Nothing is overwritten, but the page does not mention it, and using --force here would clobber the cluster's original secrets bundle. Fix: Note: talosctl gen will not overwrite an existing file; if secrets.yaml or talosconfig already exists, write to a new path (-o secrets-new.yaml, -o talosconfig-new) instead of passing --force.
```bash
talosctl gen secrets --from-controlplane-config controlplane.yaml -o secrets.yaml
```

Now, run the following commands to generate a certificate:
Then generate the `talosconfig` from the secrets bundle, as in [From secrets bundle](#from-secrets-bundle):

```bash
talosctl gen key --name admin
talosctl gen csr --key admin.key --ip 127.0.0.1
talosctl gen crt --ca ca --csr admin.csr --name admin
talosctl gen config --with-secrets secrets.yaml --output-types talosconfig -o talosconfig <cluster-name> https://<cluster-endpoint>
```

Put the base64-encoded files to the respective location to the `talosconfig`:

```yaml
context: mycluster
contexts:
mycluster:
endpoints:
- CP1
- CP2
ca: <base64-encoded ca.crt>
crt: <base64-encoded admin.crt>
key: <base64-encoded admin.key>
The generated `talosconfig` has no endpoints.

Set the endpoints to your control plane nodes:

```bash
talosctl --talosconfig talosconfig config endpoint <CP1> <CP2>
```

The secrets bundle holds every secret of the cluster. Store it securely, or delete it once the `talosconfig` is generated.
Loading