A certificate is used to guarantee trust between two parties during a transaction. For example, when a user tries to access a web server, TLS certificates ensure that the communication between the user and the server is encrypted and the server is who it says it is.
If a user were to access his online banking application the credentials such as username and password he types in would be sent in a plain text format. The hacker sniffing network traffic could easily retrieve the credentials and use them to hack into the user’s bank account. that is obviously not safe. So you must encrypt the data being transferred using encryption keys the data is encrypted using a key which is basically a set of random numbers and alphabets you add the random number to your data and you encrypted into a format that cannot be recognized the data is then sent to the server. The hacker sniffing the network gets the data but can not do anything with it. However, the same is the case with the server receiving the data it cannot decrypt that data without the encryption key. So a copy of the key must also be sent to the server so that the server can decrypt and read the message since the key is also sent over the same network. The attacker can sniff that as well and decrypt that data with it. This is known as SYMMETRIC ENCRYPTION. It is a secure way of encryption but since it uses the same key to encrypt and decrypt the data and since the key has to be exchanged between the sender and the receiver there is a risk of a hacker gaining access to the key and decrypting the data and that is where ASYMMETRIC ENCRYPTION comes in. Instead of using a single key to encrypt and decrypt data asymmetric encryption uses a pair of keys a private key and a public key.
ASYMMETRIC ENCRYPTION
Public-key cryptography, or asymmetric cryptography, is a cryptographic system that uses pairs of keys: public keys, which may be disseminated widely, and private keys, which are known only to the owner.
You have a server in the environment you need access to. You do not want to use passwords as they are too risky. So you decide to use key pairs you generate a public and private key pair. You can do this by running the ssh_keygen command
$ ssh-keygen
Generating public/private rsa key pair.It creates two files id_rsa the private key and id_rsa.pub is public key (public lock). then secure your server by locking down all access to it except through a door is locked using the public lock. It is usually done by adding an entry with the pubic key into the servers.
$ cat ~/.ssh/authorized_keys
ssh-rsa ADEWEFEFSDedf.. user1ssh -i id_ras user1@server1What if you have other servers in the environment and How do you secure more than one server with the key pair?
You can create copies of the public lock and place them on as many servers as you want. You can use the same private key to ssh into all of your servers securely.
$ cat ~/.ssh/authorized_keys
ssh-rsa ADEWEFEFSDedf.. user1
ssh-rsa AAEerfeEeF3f2.. user2How do you get your certificates signed by someone with authority?
That is where Certificate Authorities or CAs come in. They are well-known organizations that can sign and validate your certificates for you. Some of the popular ones are symantec, digicert, comodo, globalsign etc. The way this works is you generate a certificate signing a request or CSR using the key you generated earlier and the domain name of your web site. The certificate authorities verify your details and once it checks they sign the certificate and send it back to you. you now have a certificate signed by a CA that the process trusts if a hacker tried to get his certificate. CAs use different techniques to make sure that you are the actual owner of that domain.
How do the browsers know that the CA itself was legitimate?
What if the certificate was signed by a fake CA. The CAs (Symantec, Comodo, GlobalSign, etc) is themselves have a set of public and private key pairs. The CAs use their private keys to sign the certificates the public keys of all the CAs are built into the browsers. The browser uses the public key of the CA to validate that the certificate was actually signed by the CA themselves. You can actually see them in the settings of your web browser, under certificates. They are under the trusted CAs tab.
These is public CAs that help us ensure the public websites we visit. However, they do not help you validate sites hosted privately say within your organization. For example, for accessing your payroll or internal email applications. For that, you can host your own private CAs. Most of the companies such as (Symantec, Comodo, GlobalSign, etc) have a private offering of their services. A CA server that you can deploy internally within your company. You can then have the public key of your internal CA server installed on all your employees browsers and establish secure connectivity within your organization.
To encrypt messages, we use ASYMMETRIC ENCRYPTION using Public Key Infrastructure.
Naming convention. Usually, certificates with the public key(public lock, Certificate) are named .crt or .pem. Private keys are usually with extension .key or -key.pem
The Kubernetes cluster consists of a set of master and worker nodes. 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 Kubernetes cluster through the Kubectl uility or accessing the Kubernetes API directly must establish a secure TLS connection. Communication between all the components within the Kubernetes cluster also needs 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.
Server Certificates for Servers
Kubernetes Server
- Kube-apiserver [apiserver.crt, apiserver.key]
- ETCD Server [etcdserver.crt, apiserver.key]
- Kubelet Server [kubelet.crt, kubelet.key]
The apiserver exposes an HTTPS service that other components, as well as external users, use to manage the Kubernetes cluster. So it is a server and it requires certificates to secure all communication with its clients. So we generate a certificate and key pair. Another server in the cluster is the ETCD Server. The ETCD server stores all information about the cluster so it requires a pair of certificates and key for itself. The other server component in the cluster is on the worker nodes. There are the kubelet services but also expose an HTTPS API in point that the Kube-apiserver talks to interact with the worker nodes. Those are really the server components in the Kubernetes cluster.
Client Server
- Admin Server [admin.crt, admin.key]
- Kube-scheduler [kube-scheduler.crt, kube-scheduler.key]
- Kube-controller-manager [kube-controller-mananger.crt, kube-controller-manager.key]
- Kube-proxy [kube-proxy.crt, kube-proxy.key]
The clients who access the kube apiserver are the administrators through kubectl REST API the admin user requires a certificate and key pair to authenticate the kube-apiserver.
Kube-scheduler talks to the Kube-apiserver to look for pods that require scheduling and then get the API server to schedule the pods on the right worker nodes. Kube-scheduler is a client that accesses the Kube-apiserver. As far as the Kube-apiserver is concerned, the scheduler is just another client like the admin user. So, the scheduler needs to validate its identity using a client TLS certificate. So it needs its own pair of certificates and keys.
Kube-controller-manager is another client that accesses the Kube-apiserver. So, it also requires a certificate for authentication to the Kube-apiserver. So we create a certificate pair for it.
Kube-proxy requires a client certificate to authenticate to the Kube-apiserver, so it requires its own pair of certificates and keys.
Lastly, we also need Certificate Authority (CA).