Best practice to invalidate shared K3s kubeconfig
06:30 06 Dec 2025

I have a single-node K3s cluster (v1.31) on-prem using a custom data-dir (`/mnt/staging`) with SQLite datastore.

When K3s was first initialized, I shared the default admin kubeconfig (`/etc/rancher/k3s/k3s.yaml`) with a developer. I now want to:

1. Invalidate the shared kubeconfig so it no longer works

Is rotating the client CA (`/mnt/staging/server/tls/client-ca.crt` and `client-ca.key`) the correct approach? Will K3s auto-regenerate a new CA on restart?

Any gotchas or recommended approach for this?

Thanks!

kubernetes rancher k3s kubeconfig