PKI certificates and requirements [page]deterministic

setupsecurity

Kubernetes requires PKI certificates for authentication over TLS. If you install Kubernetes with [kubeadm](/docs/reference/setup-tools/kubeadm/), the certificates that your cluster requires are automatically generated. You can also generate your own certificates -- for example, to keep your private keys more secure by not storing them on the API server. This page explains the certificates that your cluster requires.

## How certificates are used by your cluster

Kubernetes requires PKI for the following operations:

### Server certificates

* Server certificate for the API server endpoint * Server certificate for the etcd server * [Server certificates](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#client-and-serving-certificates) for each kubelet (every [node](#gloss:node) runs a kubelet) * Optional server certificate for the [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)

### Client certificates

* Client certificates for each kubelet, used to authenticate to the API server as a client of the Kubernetes API * Client certificate for each API server, used to authenticate to etcd * Client certificate for the controller manager to securely communicate with the API server * Client certificate for the scheduler to securely communicate with the API server * Client certificates, one for each node, for kube-proxy to authenticate to the API server * Optional client certificates for administrators of the cluster to authenticate to the API server * Optional client certificate for the [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)

### Kubelet's server and client certificates

To establish a secure connection and authenticate itself to the kubelet, the API Server requires a client certificate and key pair.

In this scenario, there are two approaches for certificate usage:

* Shared Certificates: The kube-apiserver can utilize the same certificate and key pair it uses to authenticate its clients. This means that the existing certificates, such as `apiserver.crt` and `apiserver.key`, can be used for communicating with the kubelet servers.

* Separate Certificates: Alternatively, the kube-apiserver can generate a new client certificate and key pair to authenticate its communication with the kubelet servers. In this case, a distinct certificate named `kubelet-client.crt` and its corresponding private key, `kubelet-client.key` are created.

> Note: `front-proxy` certificates are required only when using the API server aggregation layer to support [an extension API server](/docs/tasks/extend-kubernetes/setup-extension-api-server/).

etcd also implements mutual TLS to authenticate clients and peers.

## Where certificates are stored

If you install Kubernetes with kubeadm, most certificates are stored in `/etc/kubernetes/pki`. All paths in this documentation are relative to that directory, with the exception of user account certificates which kubeadm places in `/etc/kubernetes`.

## Configure certificates manually

If you don't want kubeadm to generate the required certificates, you can create them using a single root CA or by providing all certificates. See [Certificates](/docs/tasks/administer-cluster/certificates/) for details on creating your own certificate authority. See [Certificate Management with kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) for more on managing certificates.

### Single root CA

You can create a single root CA, controlled by an administrator. This root CA can then create multiple intermediate CAs, and delegate all further creation to Kubernetes itself.

Required CAs:

| Path | Default CN | Description | |------------------------|---------------------------|----------------------------------| | ca.crt,key | kubernetes-ca | Kubernetes general CA | | etcd/ca.crt,key | etcd-ca | For all etcd-related f …(trimmed)