Let’s begin with the host that form the cluster itself.
Of course, all access to these hosts must be secured, route access disabled, password based authentication disabled and only SSH key based authentication to be made available.
And of course, any other measures you need to take to secure your physicaSl or virtual infrastructure that hosts Kubernetes.
Of course, if that is compromised, everything is compromised. Our focus in this lecture is more on Kubernetes related security.
What are the risks and what measures do you need to take to secure the cluster?
As we have seen already,
the kube-apiserver is at the center
of all operations within Kubernetes.
We interact with it through the kube control utility
or by accessing the API directly,
and through that you can perform almost any operation
on the cluster.
So that’s the first line of defense.
Controlling access to the API server itself.
We need to make two types of decisions.
Who can access the cluster and what can they do?
Who can access the API server is defined
by the authentication mechanisms.
There are different ways that you can authenticate
to the API server,
starting with user IDs and passwords stored
in static files or tokens, certificates,
or even integration with external authentication providers
like LDAP.
Finally, for machines, we create service accounts.
We will look at these in more detail
in the upcoming lectures.
Once they gain access to the cluster
what can they do is defined by authorization mechanisms.
Authorization is implemented
using role-based access controls
where users are associated to groups
with specific permissions.
In addition, there are other authorization modules
like the attribute-based access control,
Node authorizers, webhooks, et cetera.
Again, we look at these in more detail
in the upcoming lectures.
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.
We have a section entirely for this
where we discuss and practice
how to set up certificates between the various components.
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.
s