Certificate Management with kubeadm [page]deterministic

taskssecurity

Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/) expire after 1 year. This page explains how to manage certificate renewals with kubeadm. It also covers other tasks related to kubeadm certificate management.

The Kubernetes project recommends upgrading to the latest patch releases promptly, and to ensure that you are running a supported minor release of Kubernetes. Following this recommendation helps you to stay secure.

You should be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/best-practices/certificates/).

You should be familiar with how to pass a [configuration](/docs/reference/config-api/kubeadm-config.v1beta4/) file to the kubeadm commands.

This guide covers the usage of the `openssl` command (used for manual certificate signing, if you choose that approach), but you can use your preferred tools.

Some of the steps here use `sudo` for administrator access. You can use any equivalent tool.

## Using custom certificates {#custom-certificates}

By default, kubeadm generates all the certificates needed for a cluster to run. You can override this behavior by providing your own certificates.

To do so, you must place them in whatever directory is specified by the `--cert-dir` flag or the `certificatesDir` field of kubeadm's `ClusterConfiguration`. By default this is `/etc/kubernetes/pki`.

If a given certificate and private key pair exists before running `kubeadm init`, kubeadm does not overwrite them. This means you can, for example, copy an existing CA into `/etc/kubernetes/pki/ca.crt` and `/etc/kubernetes/pki/ca.key`, and kubeadm will use this CA for signing the rest of the certificates.

## Choosing an encryption algorithm {#choosing-encryption-algorithm}

kubeadm allows you to choose an encryption algorithm that is used for creating public and private keys. That can be done by using the `encryptionAlgorithm` field of the kubeadm configuration:

```yaml apiVersion: kubeadm.k8s.io/v1beta4 kind: ClusterConfiguration encryptionAlgorithm: <ALGORITHM> ```

`<ALGORITHM>` can be one of `RSA-2048` (default), `RSA-3072`, `RSA-4096` or `ECDSA-P256`.

## Choosing certificate validity period {#choosing-cert-validity-period}

kubeadm allows you to choose the validity period of CA and leaf certificates. That can be done by using the `certificateValidityPeriod` and `caCertificateValidityPeriod` fields of the kubeadm configuration:

```yaml apiVersion: kubeadm.k8s.io/v1beta4 kind: ClusterConfiguration certificateValidityPeriod: 8760h # Default: 365 days × 24 hours = 1 year caCertificateValidityPeriod: 87600h # Default: 365 days × 24 hours * 10 = 10 years ```

The values of the fields follow the accepted format for [Go's `time.Duration` values](https://pkg.go.dev/time#ParseDuration), with the longest supported unit being `h` (hours).

## External CA mode {#external-ca-mode}

It is also possible to provide only the `ca.crt` file and not the `ca.key` file (this is only available for the root CA file, not other cert pairs). If all other certificates and kubeconfig files are in place, kubeadm recognizes this condition and activates the "External CA" mode. kubeadm will proceed without the CA key on disk.

Instead, run the controller-manager standalone with `--controllers=csrsigner` and point to the CA certificate and key.

There are various ways to prepare the component credentials when using external CA mode.

### Manual preparation of component credentials

[PKI certificates and requirements](/docs/setup/best-practices/certificates/) includes information on how to prepare all the required by kubeadm component credentials manually.

This guide covers the usage of the `openssl` command (used for manual certificate signing, if you choose that approach), but you can use your preferred tools.

### Preparation of credentials by signing CSRs generated by kubeadm

kubeadm can [generate CSR files](#signing-csr) that you can sign manually with tools like `openssl` and your ex …(trimmed)