I'm excited for the content of this demo?
Why?
Because it focuses on prevention.
In other words, how could we have prevented this attack?
We're going to go into kubelet hardening, pod security
policies, and after enabling pod security policies,
we're going to attempt to launch an insecure pod and see
that Kubernetes don't play. Alright, let's get started.
We're going to kick this off by going to the
securing‑a‑cluster Kubernetes documentation.
As always,
all of these links are available within the course
notes. So where are we at right now?
In our demo environment,
we saw how various Kubernetes vulnerabilities can be chained
together to lead to full‑scale compromise.
But how do we prevent this from occurring in the first place?
Well, that's where this document comes in.
This document covers topics related to protecting a cluster
from accidental or malicious access and provides
recommendations on overall security.
I recommend that you check out this page in detail. For the purposes of
this course, we're going to focus on the kubelet area.
Let's focus on the first paragraph.
The kubelet exposes endpoints, which grant powerful control over the
node and containers. By default, kubelets allow unauthenticated access
to this API. In this course, kube‑hunter found that vulnerability, and
we were able to exploit it.
Let's dive deeper into some preventative measures for the
kubelet. Similar to the previous page, I recommend that you
check out this page in detail as well.
One of the top items that you can do is start the kubelet with the
‑‑anonymous‑auth=false flag. As a blue teamer, you might not be
implementing this hardening yourself, but it's important to
understand these options at a high level so you can advocate for
these preventative controls.
Let's go back to the original link.
One other major preventative control is the pod security policy.
Pod security policies restrict the permissions of pods. We'll
dive into this deeper within the next section.
In this slide, we're going to start getting an understanding of pod
security policies. But before we dive in there,
I just want to highlight one control that was not
stated in the previous document.
This control has to do with verifying the signature of a
Docker image before the pod is created.
Okay, so what does this mean? If the Docker image has changed,
the signature of the image will change as well.
The changes in image signatures could tip us off that
malicious activity is occurring.
In our Apache example,
we could have had a policy that mandates that only images with a particular
signature could be leveraged to create the Apache pod.
As you might expect, this policy would be persisted within the control plane.
For more information on this approach, check out the YouTube
talk, Securing your Kubernetes Delivery Pipelines with Notary
and TUF. The link is seen within the course notes. Now going
back to pod security policies.
Pod security policies restrict the permissions of pods. For example,
a pod security policy can restrict the file system paths that a pod can
leverage. Similar to the image policy that we just discussed, pod security
policies are persisted within the control plane.
Let's get out of these slides and go back to where we belong,
which is the terminal.