TLS bootstrapping [page]deterministic

reference

In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes control plane components, specifically kube-apiserver. In order to ensure that communication is kept private, not interfered with, and ensure that each component of the cluster is talking to another trusted component, we strongly recommend using client TLS certificates on nodes.

The normal process of bootstrapping these components, especially worker nodes that need certificates so they can communicate safely with kube-apiserver, can be a challenging process as it is often outside of the scope of Kubernetes and requires significant additional work. This in turn, can make it challenging to initialize or scale a cluster.

In order to simplify the process, beginning in version 1.4, Kubernetes introduced a certificate request and signing API. The proposal can be found [here](https://github.com/kubernetes/kubernetes/pull/20439).

This document describes the process of node initialization, how to set up TLS client certificate bootstrapping for kubelets, and how it works.

## Initialization process

When a worker node starts up, the kubelet does the following:

1. Look for its `kubeconfig` file 1. Retrieve the URL of the API server and credentials, normally a TLS key and signed certificate from the `kubeconfig` file 1. Attempt to communicate with the API server using the credentials.

Assuming that the kube-apiserver successfully validates the kubelet's credentials, it will treat the kubelet as a valid node, and begin to assign pods to it.

Note that the above process depends upon:

* Existence of a key and certificate on the local host in the `kubeconfig` * The certificate having been signed by a Certificate Authority (CA) trusted by the kube-apiserver

All of the following are responsibilities of whoever sets up and manages the cluster:

1. Creating the CA key and certificate 1. Distributing the CA certificate to the control plane nodes, where kube-apiserver is running 1. Creating a key and certificate for each kubelet; strongly recommended to have a unique one, with a unique CN, for each kubelet 1. Signing the kubelet certificate using the CA key 1. Distributing the kubelet key and signed certificate to the specific node on which the kubelet is running

The TLS Bootstrapping described in this document is intended to simplify, and partially or even completely automate, steps 3 onwards, as these are the most common when initializing or scaling a cluster.

### Bootstrap initialization

In the bootstrap initialization process, the following occurs:

1. kubelet begins 1. kubelet sees that it does _not_ have a `kubeconfig` file 1. kubelet searches for and finds a `bootstrap-kubeconfig` file 1. kubelet reads its bootstrap file, retrieving the URL of the API server and a limited usage "token" 1. kubelet connects to the API server, authenticates using the token 1. kubelet now has limited credentials to create and retrieve a certificate signing request (CSR) 1. kubelet creates a CSR for itself with the signerName set to `kubernetes.io/kube-apiserver-client-kubelet` 1. CSR is approved in one of two ways: * If configured, kube-controller-manager automatically approves the CSR * If configured, an outside process, possibly a person, approves the CSR using the Kubernetes API or via `kubectl` 1. Certificate is created for the kubelet 1. Certificate is issued to the kubelet 1. kubelet retrieves the certificate 1. kubelet creates a proper `kubeconfig` with the key and signed certificate 1. kubelet begins normal operation 1. Optional: if configured, kubelet automatically requests renewal of the certificate when it is close to expiry 1. The renewed certificate is approved and issued, either automatically or manually, depending on configuration.

The rest of this document describes the necessary steps to configure TLS Bootstrapping, and its limitations.

## Configuration

To configure for TLS bootstrapping and optional a …(trimmed)