Security:

Security primitives:
All communication with the cluster between the various components such as the
ETCD cluster, the kube-controller-manager, scheduler, API server, as well as those
running on the worker nodes such as the Kubelet and the kube-proxy is secured using
TLS encryption.
What about communication between applications within the cluster?
By default, all Pods can access all other Pods within the cluster.
Now, you can restrict access between them using network policies.

Authentication:
All user access is managed by the API server, whether you're accessing the cluster
through Kubecontrol tool or the API directly. All of these requests go through the
Kube API server. The Kube API server authenticates the request before processing it.
So how does the Kube API server authenticate?
There are different authentication mechanisms that can be configured. You can have a
list of username and passwords in a static password file or usernames and tokens in a
static token file or you can authenticate using certificates. And another option is to
connect to third party authentication protocols like LDAP, Kerberos et cetera.
Static Password File: You can create a list of users and their passwords in a CSV file
and use that as the source for user information.
The file has three columns, password, username, and user ID. We then pass the file
name as an option to the Kube API server.

Static token file:

TLS Introduction:

TLS Basics: 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.

Scenerio1: Without secure connectivity, if a user were to access his online banking
application, the credentials he types in would be sent in a plain text format. The
hacker sniffing network traffic could easily retrieve the credentials and use it to hack
into the user's bank account.

Symmetric Encryption: 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
encrypt it 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't do anything with it.
However, the same is the case with the server receiving the data. It cannot decrypt the
data without the 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 the data with it.

Asymmetric Encryption: 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.

Example: The problem we had earlier with symmetric encryption was that the key
used to encrypt data had to be sent to the server over the network along with the
encrypted data, and so there is a risk of the hacker getting the key to decrypt the data.
What if we could somehow get the key to the server safely?
Once the key is safely made available to the server, the server and client can safely
continue communication with each other using symmetric encryption. To securely
transfer the symmetric key from the client to the server, we use asymmetric
encryption.
So, we generate a public and private key pair on the server (Bank Server).
When the user first accesses the web server using HTTPS, he gets the public key from
the server. Since the hacker is sniffing all traffic, let us assume he too gets a copy of
the public key.
The user, in fact, the user's browser then encrypts the symmetric key using the public
key provided by the server. The symmetric key is now secure. The user then sends
this to the server. The hacker also gets a copy. The server uses the private key to
decrypt the message and retrieve the symmetry key from it. However, the hacker does
not have the private key to decrypt and retrieve the symmetric key from the message it
received.

So, let's summarize real quick. We have seen why you may want to encrypt messages
being sent over a network. To encrypt messages, we use asymmetric encryption
with a pair of public and private keys. An admin uses a pair of keys to secure SSH
connectivity to the servers. The server uses a pair of keys to secure a STPS traffic.
But for this, the server first sends a certificate signing request to a CA, the CA uses its
private key to sign the CSR. Remember, all users have a copy of the CAs public key.
The signed certificate is then sent back to the server. The server configures the web
application with the signed certificate. Whenever a user accesses the web application,
the server first sends the certificate with its public key. The user, or rather the user's
browser reads the certificate and uses the CAs public key to validate and retrieve the
server's public key. It then generates a symmetric key that it wishes to use going
forward for all communication. The symmetric key is encrypted using the server's
public key and sent back to the server. The server uses its private key to decrypt the
message and retrieve the symmetric key. The symmetric key is used for
communication going forward.
This whole infrastructure, including the CA, the servers, the people, and the process
of generating, distributing and maintaining digital certificates is known as public key
infrastructure or PKI.

Usually, certificates with public key are named crt or pem extension, so that's
server.crt, server.pem for server certificates or client.crt, or client.pem for client
certificates. And private keys are usually with extension .key or -key.pem.

TLS In Kubernetes:

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.
TLS In Kubernetes: Certificate creation

To generate certificates, there are different tools available such as Easy-RSA,

OpenSSL, or CFSSL, et cetera, or many others.

The CA now has its private key and route certificate file.
View Certificate details:
Certificates API:
Kubernetes has a built-in certificate API

1. A user first creates a key, then generates a certificate signing request using the
key with her name on it, then sends the request to the administrator.
2. The administrator takes a key and creates a CertificateSigningRequest object.
The CertificateSigningRequest object is created like any other Kubernetes
object, using a manifest file with the usual fields.

3.

4. View the certificate by viewing it in a YAML format. The generated certificate

is part of the output, but as before, it is in a base64 encoded format. To decode
it, take the text and use the base64 utilities, decode option. This gives the
certificate in a plain text format. This can then be shared with the end user.
All the certificate related operations are carried out by the Controller Manager.
 KUBE CONFIGS:

Send a CURL request to the address of the kube-apiserver while passing in the bearer
files, along with the CA certificate as options. This is then validated by the API server
to authenticate the user. Now, how do you do that while using the kubectl command?

Obviously, typing those in every time is a tedious task, so you move this information
to a configuration file called as kubeconfig.

By default, the kubectl tool looks for a file named config under a directory kube under
the user's home directory. So if you keep the kubeconfig file there, you don't have to
specify the path to the file explicitly in the kubectl command.
That's the reason you haven't been specifying any options for your kubectl commands
so far.
API Groups:

Authorization:
RBAC: Role based authorization.
We do that by creating a role object.

The next step is to link the user to that role. For this, we create another object called
roll binding. The roll binding object links a user object to a role. We will name it dev
user to Developer Binding.

The kind is role binding. It has two sections. The subjects is where we specify the user
details. The roll ref section is where we provide the details of the roll we created.
Create the role binding using the cube control create command.
Also note that the roles and role bindings fall under the scope of name spaces.
So here the dev user gets access to pod and convict maps within the default name
space. If you want to limit the dev user's access within a different name space
then specify the name space within the metadata of the definition file while creating
them.
.
Cluster Roles:

How do we authorize users to cluster-wide resources like nodes or persistent volumes.

That is where you use cluster roles and cluster role bindings. Cluster roles are just like
roles, except they are for cluster-scoped resources.
For example, a cluster admin role can be created to provide a cluster administrator
permissions to view, create, or delete nodes in a cluster.
Similarly, a storage administrator role can be created to authorize a storage admin
to create persistent volumes and claims.

We said that cluster roles and binding are used for cluster-scoped resources, but that is
not a hard rule. You can create a cluster role for namespaced resources as well.
When you do that, the user will have access to these resources across all namespaces.

Service account:
There are two types of accounts in Kubernetes: a user account and a service account.
When the service account is created, it also creates a token automatically.
The service account token is what must be used by the external application
while authenticating to the Kubernetes API.
The token, however, is stored as a secret object. In this case, it's named dashboard -sa
-token -kbbdm. So when a service account is created, it first creates the service
account object, and then generates a token for the service account. It then creates a
secret object and stores that token inside the secret object. The secret object is then
linked to the service account. To view the token, view the secret object by running the
command kubectl describe secret. This token can then be used as an authentication
bearer token while making a REST call to the Kubernetes API.
But what if your third-party application is hosted on the Kubernetes cluster
itself?

For example, we can have our custom Kubernetes dashboard application or the
Prometheus application deployed on the Kubernetes cluster itself.
In that case, this whole process of exporting the service account token and configuring
the third-party application to use it can be made simple by automatically mounting
the service token secret as a volume inside the pod hosting the third-party application.
That way, the token to access the Kubernetes API is already placed inside the pod
and can be easily read by the application. You don't have to provide it manually.

There is a default service account that exists already.

For every name space in Kubernetes, a service account named default is automatically
created. Each namespace has its own default service account. Whenever a pod is
created, the default service account and its token are automatically mounted to that
pod as a volume mount.
Check from inside of POD

Default service account is very much restricted.

It only has permission to run basic Kubernetes API queries.
Image Security:
We have used the Nginx image to deploy an Nginx container. Let's take a closer look
at this image name. The name is Nginx but what is this image and where is this image
pulled from?
This name follows Docker's image naming convention. Nginx here is the image or the
repository name. When you say Nginx, it's actually library slash Nginx. The first part
stands for the user or the account name. So, if you don't provide a user or account
name, it assumes it to be library. Library is the name of the default account where
Docker's official images are stored. These images promote best practices and are
maintained by a dedicated team who are responsible for reviewing and publishing
these official images. Now, if you were to create your own account
and create your own repositories or images under it, then you would use a similar
pattern. So instead of library, it would be your name or your company's name.
Now, where are these images stored and pulled from?
Since we have not specified the location where these images are to be pulled from,
it is assumed to be Docker's default registry, Docker hub.

The DNS name for which is docker.io. The registry is where all the images are stored.
Whenever you create a new image or update an image, you push it to the registry
and every time anyone deploys this application, it is pulled from the registry.
There are many other popular registries as well. Google's registry is at gcr.io, where a
lot of Kubernetes related images are stored, like the ones used for performing end-to-
end tests on the cluster. These are all publicly accessible images that anyone can
download and access.

When you have applications built in-house that shouldn't be made available to the
public, hosting an internal private registry may be a good solution.
Many cloud service providers, such as AWS, Azure or GCP, provide a private registry
by default.

To use an image from our private registry, we replace the image name with the full
path to the one in the private registry.
But how do we implement the authentication, the login part?
How does Kubernetes get the credentials to access the private registry?
Within Kubernetes, we know that the images are pulled and run by the Docker run
time on the worker nodes. How do you pass the credentials to the docker run times on
the worker nodes?
For that, we first create a secret object with the credentials in it.
The secret is of type docker registry, and we name it regcred.
Docker registry is a built-in secret type that was built for storing Docker credentials.
We then specify the registry server name, the username to access the registry, the
password, and the email address of the user. We then specify the secret inside our pod
definition file under the image pull secret section. When the pod is created,
Kubernetes or the kubelets on the worker node uses the credentials from the secret to
pull images.
Security Context:
In Kubernetes, containers are encapsulated in Pods. You may choose to configure the
security settings at a container level or at a Pod level.
If you configure it at a Pod level, the settings will carry over to all the containers
within the Pod. If you configure it at both the Pod and the container, the settings on
the container will override the settings on the Pod.

At POD level:

At Container level:
Network Policy:
Network policy is another object in the Kubernetes namespace just like pods, replica
sets or services, you link a network policy to one or more pods.
You can define rules within the network policy.

How do you apply or link a network policy to a pod?

We use the same technique that was used before to link replica sets or services to pod,
labels and selectors. We label the pod and use the same labels on the port selector
field in the network policy and then we build our rule.
Under policy types, specify whether the rule is to allow ingress or egress traffic or
both.