Now we're back at our original demo environment slide.
We're going to use this slide to do a brief recap on the kubelet.
So as we see,
the kubelet downloads the Apache image from the registry and
uses the image to instantiate the Apache pod.
Also, for the kubelet to control the Apache pod,
it needs a lot of permissions,
which obviously makes this a huge target for attackers.
Now, as a result of these permissions,
the kubelet can run commands within the Apache pod.
When we ran the initial kube‑hunter scan,
it showed the kubelet allowed unauthenticated access.
In other words,
this would allow an attacker to run commands within the Apache pod.
Before we proceed in our investigation,
let's look at the evidence we have collected so far.
We are going to leverage the investigation chain slide to
track our progress through our investigation.
When we first ran kube‑hunter, there was a couple of findings,
the kubelet remote code execution and the /pods metadata endpoint.
Then we leveraged Nmap to get another perspective of the
services running within Kubernetes.
Nmap then went ahead and found Heartbleed.
Given the Heartbleed vulnerability,
we wanted to dive deeper into the Apache service,
so we looked at the kubelet's /pods metadata endpoint . The pod
endpoint disclosed a couple of valuable pieces of information
specifically related to the Apache pod.
We found the Docker image name, and we also saw that the host file
system was potentially mounted within the pod.
Oh my goodness!
So let's zoom out here a little bit. So an attacker can run
commands within pods, and they also potentially have read‑only
access to the entire file system.
Given that information,
I wonder if an attacker found credentials within the file system.
We can perform this audit ourselves using a tool called shhgit.
I know it sounds kind of funny.
This tool allows us to search for credentials within Git repos and within the
file system itself. We'll use this tool in our next segment.