The certificates called the root certificates are configured on the Certificate Authority servers (CA).
The clients certificates are configured on the clients.
If a machine acts as a server when receiving requests and as a client when sending requests, it will have both server and client certificate.
Formats of the certificates with public keys:
Formats of the Private keys:
The communication between the kubernetes master and the worker nodes need to be secure and encrypted. A user connecting the the API server for example needs a TLS, also all the communications between the kubernetes elements need to be secure.
Example: "kube-API server"
The Kube-API server requires a certificate to secure communications with its clients, for that purpose it uses a certificate and a private key ( kube-api.crt + kube-api.key )
The etcd server:
The etcd server also requires a certificate and a key to communicate securely with the Kube-API (etcd.crt + etcd.key)
The kubelet server:
The kubelet server also requires a certificate and a key (kubelet.crt + kubelet.key).
The https protocol:
All the above elements expose an https server that the clients can communicate with.
A user connecting to the Kube-API:
We have a user named "user" for example.
User will need a certificate a key pair to connect to the API server (user.crt + user.key)
The servers acting as clients:
The scheduler server can also acts as a client to send requests to the API server.
For that purpose it needs also a certificate and a key (scheduler.crt + scheduler.key). The API server is the only server that communicates with the etcd server , it acts as a client when requesting data from the etcd server so it also needs a certificate and a key (kube-api.crt , kube-api.key)
The certificate Authority:
We require a certificate authority to sign all the above certificates.
The certificate Authority also has it pair of certificate and keys ( CA.cert + CA.key)
Generating the certificates:
In order to generate the certificates, we have lot of tools like (openssl, cfssl, ...)
Creating the keys and a certificate using openssl:
Creating a key for the CA (Certificate Authority):
Generating a certificate signing request:
The "ca.csr" file is the root certificate.
CN: describes the component requesting the certificate
Signing the certificate:
We sign the certificate with the certificate generated in the previous command "ca.csr":
Generating the client certificates:
Generating the private key for the user:
Generate a certificate signing request:
O=system:masters: adds the user to the admin group in the certificate.
Generating a signed certificate using the "ca.crt" certificate:
We specify the CA certificate and the CA key.
The signed certificate is written in the user.crt file which is the certificate that the "user" uses to authenticate with the cluster.
Creating a certificate and a key is the equivalent to creating a username and a password The certificate is the equivalent of a valid username and the key is the equivalent of the password.
Using the certificates to connect to the API-server:
For the user to connect to the api-server, we use the below:
The CA certificate is optional in the above command.
We can put all the above information in a kubeconfig.yaml file and pass the configuration file as a parameter to our command.
The CA certificate:
To be able to validate each other all the kubernetes components need a copy of the CA certificate.