Hello and welcome to this lecture notes lecture, we look at securing your cabinet, as Closter would
tell us certificate's.
In the previous lecture we saw what public and private keys are, how a server uses public and private
keys to secure connectivity.
We will call them service certificates.
We saw what a certificate authority is.
We learned that the CIA has its own set of public and private keepers that it uses to sign service certificates.
We will call them RWD certificates.
We also saw how a server can request a client to verify themselves using client certificates.
So three types of certificates, several certificates configured on the service road certificate configured
on the ACA servers and then client certificates configured on the clients.
And a quick note on naming convention before we go forward.
You're going to see a lot of certificate files in this lecture and it could be very confusing.
So use this technique to know which one is which.
Usually certificates with public keys are named CRT or pen extension.
So that's server CRT or server not for server certificates or Kleinig CRT or Kleinwort Pen for client
certificates.
And private keys are usually with extension docky or with Hadash Key in the filenames, for example.
Server key, also server dot.
So just remember, private keys have the word key in them, usually either as an extension or in the
name of the certificate and one that doesn't have the word key in them is usually a public key or certificate.
That's how I remember it.
We will now see how these concepts relate to a cabinet as Kluster.
The cabinet is Closter consists of a set of master and worker notes, of course, all communication
between these nodes need to be secure and must be encrypted.
All interactions between all services and their clients need to be secure.
For example, an administrator interacting with the cabinet is clustered through the keep control utility
or via accessing the cabinet.
Is API directly must establish security, close connection.
Communication between all the components within the governor's cluster also need to be secured.
So the two primary requirements are to have all the various services within the cluster to use server
certificates and all clients to use client certificates to verify they are who they say they are.
Let's look at the different components within the Cabinet as cluster and identify the various servers
and clients and who talks to who.
Let's start with the Kubi server.
As we know already, the API server exposes and a service that other components as well as external
users use to manage the companies cluster.
So it is a server and it requires certificates to secure all communication with its clients.
So we generate a certificate and keep here.
We call it API server, DOT CERT and API several darcie.
We will try to stick to this naming convention going forward.
Anything with a CRT extension is the certificate and DOT key extension is the private key.
Also remember, the certificate names could be different in different coroneted setups depending on
who and how the cluster was set up.
So these names may be different in yours.
In this lecture, we will try to use names that help us easily identify the cert files.
Another server in the cluster is the ETSI, the server, the ETSI, the server stores, all the information
about the cluster, so it requires a pair of certificate and key for itself.
We will call it SCD server, DOT, CRT and SCD server that keep the other server component in the cluster
is on the worker nodes.
There are the Kubla services.
They also expose an API endpoint that the Cube API server talks to to interact with the worker nodes.
Again, that requires a certificate and keeper.
We call it Cumulate Dot Sword and Kubelik Key.
Those are really the sole components in the Covenant, is Kloster.
Let's now look at the client components, who are the clients who access the services, the clients
who access the Cuba parts of are us.
The administrators to keep control arrested by the admin user requires a certificate and keeper to authenticate
to the server.
We will call it admin DOT, CRT and admin Darcie.
The scheduler talks to the API server to look for parts that require scheduling and then get the API
server to schedule the parts on the right worker notes.
The scheduler is a client that accesses the API server.
As far as the API server is concerned, the scheduler is just another client, like the admin user.
So the scheduler needs to validate its identity using a client certificate so it needs its own payroll
certificate and keys.
We will call it scheduler Dodsworth and scheduler Key.
The cube controller manager is another client that accesses the Cube API server, so it also requires
a certificate for authentication to the server.
So we create a certificate, prepare for it.
The last client component is the Q proxy, the Q proxy requires a client certificate to authenticate
to the API server and so it requires its own pair of certificate and keys.
We will call them Q proxy DOT CRT and Q Proxy DOT.
Keep the servers communicate amongst them as well.
For example, the API server communicates with the server.
In fact, of all the components, the Cube API server is the only server that talks to the server.
So as far as the server is concerned, the Cube API server is a client, so it needs to authenticate.
The API server can use the same keys that it used earlier for serving its own API service.
The API server, that CRT and the server key files.
Or you can generate a new pair of certificates specifically for the server to authenticate to the server.
The Kubi server also talks to the Kubelik server on each of the individual notes.
That's how it monitors the worker notes for this.
Again, it can use the original certificates or generate new ones specifically for this purpose.
So that's too many certificates.
Let's try and group them.
There are a set of client certificates mostly used by clients to connect to the server, and there are
a set of server side certificates used by the server, SCD server and Kubla to authenticate their clients.
We will now see how to generate these certificates.
As we know already, we need a certificate authority to sign all of these certificates.
Coordinators requires you to have at least one certificate authority for your customer.
In fact, you can have more than one one for all the components in the cluster and another one specifically
for Exelis.
That case, the SCD server certificates and the servers client certificates, which in this case is
the API server client certificate will be all signed by the ETSI, the server servers.
For now, we will stick to just one seet for our customer.
The CI.
A. as we know, has its own pair of certificate and key.
We will call it see a dog and see a dot key.
That should sum up all the certificates used in the cluster.