Provision a certificate authority

Where you are

In this act you create all of the cluster’s identity material first, then you start the runtimes. Nothing is running yet. This lab makes the trust root: a certificate authority and the TLS certificates that every Kubernetes component will use to prove who it is. You produce trust material here and copy it to the machines. You start no services.

In this lab you provision a public key infrastructure using openssl to bootstrap a certificate authority, and you generate TLS certificates for these components: kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, and kube-proxy. Run the commands in this section from the jumpbox.

Provision the certificate authority

In this section you provision a certificate authority that can generate the TLS certificates for the other Kubernetes components. Setting up a CA and generating certificates with openssl can take time, especially the first time you do it. To keep this lab short, an openssl configuration file named ca.conf is included. It defines the details needed to generate certificates for each Kubernetes component.

Review the ca.conf configuration file:

cat ca.conf

You do not need to understand everything in the ca.conf file to finish this tutorial. Treat it as a starting point for learning openssl and the configuration that goes into managing certificates.

Every certificate authority starts with a private key and a root certificate. In this section you create a self-signed certificate authority. That is all you need for this tutorial, but it is not something you would do in a real production environment.

Generate the CA configuration file, certificate, and private key:

{
  openssl genrsa -out ca.key 4096
  openssl req -x509 -new -sha512 -noenc \
    -key ca.key -days 3653 \
    -config ca.conf \
    -out ca.crt
}

Results:

ca.crt ca.key

Create client and server certificates

In this section you generate client and server certificates for each Kubernetes component, plus a client certificate for the Kubernetes admin user.

Generate the certificates and private keys:

certs=(
  "admin" "node-0" "node-1"
  "kube-proxy" "kube-scheduler"
  "kube-controller-manager"
  "kube-api-server"
  "service-accounts"
)

for i in ${certs[*]}; do
  openssl genrsa -out "${i}.key" 4096

  openssl req -new -key "${i}.key" -sha256 \
    -config "ca.conf" -section ${i} \
    -out "${i}.csr"

  openssl x509 -req -days 3653 -in "${i}.csr" \
    -copy_extensions copyall \
    -sha256 -CA "ca.crt" \
    -CAkey "ca.key" \
    -CAcreateserial \
    -out "${i}.crt"
done

The command above generates a private key, a certificate request, and a signed SSL certificate for each Kubernetes component. List the generated files:

ls -1 *.crt *.key *.csr

These certificates secure every connection between Kubernetes components. When two components talk to each other, each one presents its certificate to prove its identity, and each one checks that the other’s certificate was signed by your certificate authority. A component without a valid certificate cannot join the conversation.

PHI lens. Every connection between Kubernetes components is authenticated with these certificates. In a healthcare cluster that handles protected health information (PHI), that certificate identity is what lets you prove who accessed the API and reject anything unidentified. You create this trust before any patient data could ever move.

Distribute the client and server certificates

In this section you copy the certificates to every machine, placing each one where its Kubernetes component looks for its certificate pair. In a real environment, treat these certificates as sensitive secrets. The components use them as credentials to authenticate to each other.

Copy the appropriate certificates and private keys to the node-0 and node-1 machines:

for host in node-0 node-1; do
  ssh root@${host} mkdir /var/lib/kubelet/

  scp ca.crt root@${host}:/var/lib/kubelet/

  scp ${host}.crt \
    root@${host}:/var/lib/kubelet/kubelet.crt

  scp ${host}.key \
    root@${host}:/var/lib/kubelet/kubelet.key
done

Copy the appropriate certificates and private keys to the server machine:

scp \
  ca.key ca.crt \
  kube-api-server.key kube-api-server.crt \
  service-accounts.key service-accounts.crt \
  root@server:~/

The kube-proxy, kube-controller-manager, kube-scheduler, and kubelet client certificates will be used to generate client authentication configuration files in the next lab.

Key terms

Certificate authority (CA). The trust root. It is the private key and root certificate that sign every other certificate in the cluster. Components trust a certificate because they can verify the CA signed it.

TLS certificate. A file that binds an identity (such as kube-api-server or node-0) to a public key. A component presents its certificate to prove who it is when another component connects to it.

CA signing. The step where the certificate authority uses its private key to stamp a certificate as valid. The openssl x509 -req ... -CA ca.crt -CAkey ca.key command performs this signing.

Public and private key. A matched pair of keys. The private key stays secret on the machine that owns it. The public key is shared inside the certificate. Data verified with the public key proves it came from the holder of the private key, which is how a component proves its identity without revealing its secret.

Reflect

You signed every component’s certificate with one certificate authority. If that single CA private key (ca.key) were copied off the jumpbox by someone you did not authorize, what could they do, and why does that make the CA the most important secret in the cluster?

Next: Generate kubeconfig files