A CA has its own private and public keypairs - these are Root Certificates.
A Server has its own certificates - Certificate (Public Key) and Private Key.
A client also has Client Certificates as well.
Certificates with public keys are usually have a .pem or .crt extension.
Private Keys have a .key or -key.pem.
The Admin when connecting to the Master Server’s kube-apiserver has to do so via TLS. Same when going from the kube-apiserver to the kube-scheduler - that also has to be secured via TLS.
The Master Node to the Worker Nodes also need to be secured with certificates.
A Kubernetes Cluster uses Server Certificates for Servers and Client Certificates for Clients
Server Components
The kube-apiserver exposes an HTTPS service that the cluster and users use to connect.
The kube-apiserver has its own apiserver.crt certificate and apiserver.key files.
The certificate names can change depending on the setup.
Another server in the cluster is the etcd server. This stores information about the cluster. This has the following files:
etcdserver.crt
etcdserver.key
The other server in the cluster is on the Worker Nodes - these are the kubelet services or kubelet server.
This has the following files:
kubelet.crt
kubelet.key
Client Components
The Admin requires an admin.crt and admin.key to interact with the kube-apiserver.
The Admin interacts via the kubectl REST API.
The kube-scheduler communicates with the kube-apiserver to work out which pods need scheduling.
The scheduler has the following:
scheduler.crt
scheduler.key
The scheduler is a client that access the kube-apiserver.
The kube-controller-manager is another client that access the kube-apiserver.
This has these pairs of files:
controller-manager.crt
controlller-manager.key
The last client component is the kube-proxy.
This also requires its own pairs of certificates:
kube-proxy.crt
kube-proxy.key
The components even connect amongst each other, for example the kube-apiserver communicates to the etcd-server.
The kube-apiserver is the only server that talks to the etcd-server.
The kube-apiserver can use the same keys apiserver.crt and apiserver.key as mentioned above as API keys.
Can also generate a pair of separate for the kube-apiserver, to then authenticate directly to the etcd-server. These are:
apiserver-etcd-client.crt
apiserver-etcd-client.key
The kube-apiserver also communicates with the kubelet on each work node. It can either use the original apiserver.crt and apiserver.key certificates or specifically generate its own certificates with:
apiserver-kubelet-client.crt
apiserver-kubelet-client.key
Kubernetes requires that all of the above certificates need to be signed by a Certificate Authority.
At least one Certificate Authority needs to be present on the cluster.
You can have a configuration where there are multiple Certificate Authoritys present in the cluster, one for the etcd-server and kube-apiserver and then one for everything else.
The certificate authority’s certificate will be the following: