We're going to leverage kubectl to apply the Pod security policy changes.
Now it's time to see the Pod security policy in action.
We'll use K9s to view the state of our Kubernetes cluster. Pod security
policies are applied during Pod creation or Pod updates.
So if we kill this Apache Pod, it shouldn't be able to respond.
I'm going to Ctrl+K to kill this Apache Pod.
Boom, there it goes.
Okay,
so we're not seeing it come back. I'm going to press 0 to see all
Kubernetes components across all namespaces.
The kube‑controller‑manager sits in the control plane, and it
is in charge of spawning the Apache Pod.
Let's check out the logs for the kube‑controller‑manager.
I'm going to press l for logs. Now,
I'm going to hit f for full screen and w to wrap the
text. And dang, check that out.
We clearly see the Pod security policy is denying the
over‑privileged Pod for being created.
Nice.
And check this out, hostPath volumes are not allowed to be used.
Boom, there we go.
Now this isn't a comprehensive overview of Pod security policies,
but hopefully this should illustrate an option that is available in Kubernetes.
Even if you, the blue teamer, are not directly implementing this
control, having a high‑level understanding allows you to advocate for
Pod security policies within your workplace.
Now,
one thing I just wanted to say is that the Pod security policy
specification is currently in beta phase, so the details here
might change in future Kubernetes releases.
In other words, there are no guarantees moving forward.
Let's do a recap of what we just learned.
We saw how we could prevent the overarching attack
that occurred within this course.
Further, we dived into kubelet hardening.
We also saw Pod security policies.
Then we attempted to launch an insecure Pod. And then we saw the wrath of
Kubernetes and Pod security policies just straight up deny it.