PKI certificates and requirements

Kubernetes requires PKI certificates for authentication over TLS. If you install Kubernetes with 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:

  • Client certificates for the kubelet to authenticate to the API server
  • Kubelet server certificates for the API server to talk to the kubelets
  • Server certificate for the API server endpoint
  • Client certificates for administrators of the cluster to authenticate to the API server
  • Client certificates for the API server to talk to the kubelets
  • Client certificate for the API server to talk to etcd
  • Client certificate/kubeconfig for the controller manager to talk to the API server
  • Client certificate/kubeconfig for the scheduler to talk to the API server.
  • Client and server certificates for the front-proxy

Note: front-proxy certificates are required only if you run kube-proxy to support an 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 for details on creating your own certificate authority. See Certificate Management with kubeadm 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:

pathDefault CNdescription
ca.crt,keykubernetes-caKubernetes general CA
etcd/ca.crt,keyetcd-caFor all etcd-related functions
front-proxy-ca.crt,keykubernetes-front-proxy-caFor the front-end proxy

On top of the above CAs, it is also necessary to get a public/private key pair for service account management, sa.key and sa.pub. The following example illustrates the CA key and certificate files shown in the previous table:

  1. /etc/kubernetes/pki/ca.crt
  2. /etc/kubernetes/pki/ca.key
  3. /etc/kubernetes/pki/etcd/ca.crt
  4. /etc/kubernetes/pki/etcd/ca.key
  5. /etc/kubernetes/pki/front-proxy-ca.crt
  6. /etc/kubernetes/pki/front-proxy-ca.key

All certificates

If you don’t wish to copy the CA private keys to your cluster, you can generate all certificates yourself.

Required certificates:

Default CNParent CAO (in Subject)kindhosts (SAN)
kube-etcdetcd-caserver, client<hostname>, <Host_IP>, localhost, 127.0.0.1
kube-etcd-peeretcd-caserver, client<hostname>, <Host_IP>, localhost, 127.0.0.1
kube-etcd-healthcheck-clientetcd-caclient
kube-apiserver-etcd-clientetcd-casystem:mastersclient
kube-apiserverkubernetes-caserver<hostname>, <Host_IP>, <advertise_IP>, [1]
kube-apiserver-kubelet-clientkubernetes-casystem:mastersclient
front-proxy-clientkubernetes-front-proxy-caclient

[1]: any other IP or DNS name you contact your cluster on (as used by kubeadm the load balancer stable IP and/or DNS name, kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster, kubernetes.default.svc.cluster.local)

where kind maps to one or more of the x509 key usage, which is also documented in the .spec.usages of a CertificateSigningRequest type:

kindKey usage
serverdigital signature, key encipherment, server auth
clientdigital signature, key encipherment, client auth

Note: Hosts/SAN listed above are the recommended ones for getting a working cluster; if required by a specific setup, it is possible to add additional SANs on all the server certificates.

Note:

For kubeadm users only:

  • The scenario where you are copying to your cluster CA certificates without private keys is referred as external CA in the kubeadm documentation.
  • If you are comparing the above list with a kubeadm generated PKI, please be aware that kube-etcd, kube-etcd-peer and kube-etcd-healthcheck-client certificates are not generated in case of external etcd.

Certificate paths

Certificates should be placed in a recommended path (as used by kubeadm). Paths should be specified using the given argument regardless of location.

Default CNrecommended key pathrecommended cert pathcommandkey argumentcert argument
etcd-caetcd/ca.keyetcd/ca.crtkube-apiserver—etcd-cafile
kube-apiserver-etcd-clientapiserver-etcd-client.keyapiserver-etcd-client.crtkube-apiserver—etcd-keyfile—etcd-certfile
kubernetes-caca.keyca.crtkube-apiserver—client-ca-file
kubernetes-caca.keyca.crtkube-controller-manager—cluster-signing-key-file—client-ca-file, —root-ca-file, —cluster-signing-cert-file
kube-apiserverapiserver.keyapiserver.crtkube-apiserver—tls-private-key-file—tls-cert-file
kube-apiserver-kubelet-clientapiserver-kubelet-client.keyapiserver-kubelet-client.crtkube-apiserver—kubelet-client-key—kubelet-client-certificate
front-proxy-cafront-proxy-ca.keyfront-proxy-ca.crtkube-apiserver—requestheader-client-ca-file
front-proxy-cafront-proxy-ca.keyfront-proxy-ca.crtkube-controller-manager—requestheader-client-ca-file
front-proxy-clientfront-proxy-client.keyfront-proxy-client.crtkube-apiserver—proxy-client-key-file—proxy-client-cert-file
etcd-caetcd/ca.keyetcd/ca.crtetcd—trusted-ca-file, —peer-trusted-ca-file
kube-etcdetcd/server.keyetcd/server.crtetcd—key-file—cert-file
kube-etcd-peeretcd/peer.keyetcd/peer.crtetcd—peer-key-file—peer-cert-file
etcd-caetcd/ca.crtetcdctl—cacert
kube-etcd-healthcheck-clientetcd/healthcheck-client.keyetcd/healthcheck-client.crtetcdctl—key—cert

Same considerations apply for the service account key pair:

private key pathpublic key pathcommandargument
sa.keykube-controller-manager—service-account-private-key-file
sa.pubkube-apiserver—service-account-key-file

The following example illustrates the file paths from the previous tables you need to provide if you are generating all of your own keys and certificates:

  1. /etc/kubernetes/pki/etcd/ca.key
  2. /etc/kubernetes/pki/etcd/ca.crt
  3. /etc/kubernetes/pki/apiserver-etcd-client.key
  4. /etc/kubernetes/pki/apiserver-etcd-client.crt
  5. /etc/kubernetes/pki/ca.key
  6. /etc/kubernetes/pki/ca.crt
  7. /etc/kubernetes/pki/apiserver.key
  8. /etc/kubernetes/pki/apiserver.crt
  9. /etc/kubernetes/pki/apiserver-kubelet-client.key
  10. /etc/kubernetes/pki/apiserver-kubelet-client.crt
  11. /etc/kubernetes/pki/front-proxy-ca.key
  12. /etc/kubernetes/pki/front-proxy-ca.crt
  13. /etc/kubernetes/pki/front-proxy-client.key
  14. /etc/kubernetes/pki/front-proxy-client.crt
  15. /etc/kubernetes/pki/etcd/server.key
  16. /etc/kubernetes/pki/etcd/server.crt
  17. /etc/kubernetes/pki/etcd/peer.key
  18. /etc/kubernetes/pki/etcd/peer.crt
  19. /etc/kubernetes/pki/etcd/healthcheck-client.key
  20. /etc/kubernetes/pki/etcd/healthcheck-client.crt
  21. /etc/kubernetes/pki/sa.key
  22. /etc/kubernetes/pki/sa.pub

Configure certificates for user accounts

You must manually configure these administrator account and service accounts:

filenamecredential nameDefault CNO (in Subject)
admin.confdefault-adminkubernetes-adminsystem:masters
kubelet.confdefault-authsystem:node:<nodeName> (see note)system:nodes
controller-manager.confdefault-controller-managersystem:kube-controller-manager
scheduler.confdefault-schedulersystem:kube-scheduler

Note: The value of <nodeName> for kubelet.conf must match precisely the value of the node name provided by the kubelet as it registers with the apiserver. For further details, read the Node Authorization.

  1. For each config, generate an x509 cert/key pair with the given CN and O.

  2. Run kubectl as follows for each config:

  1. KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
  2. KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
  3. KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
  4. KUBECONFIG=<filename> kubectl config use-context default-system

These files are used as follows:

filenamecommandcomment
admin.confkubectlConfigures administrator user for the cluster
kubelet.confkubeletOne required for each node in the cluster.
controller-manager.confkube-controller-managerMust be added to manifest in manifests/kube-controller-manager.yaml
scheduler.confkube-schedulerMust be added to manifest in manifests/kube-scheduler.yaml

The following files illustrate full paths to the files listed in the previous table:

  1. /etc/kubernetes/admin.conf
  2. /etc/kubernetes/kubelet.conf
  3. /etc/kubernetes/controller-manager.conf
  4. /etc/kubernetes/scheduler.conf