Let's check out an example of a Pod Security Policy.
First off,
we define some permissions that allow the Pod Security Policies to execute.
Going through these is a little beyond the scope of this course.
So for us to get up and running with Pod Security Policies,
there's two items that we need. First, by default, the Pod
Security Policy feature is not enabled in Kubernetes,
so when a user of Kubernetes launches a pod,
that individual can give the pod access to any volume on the file system.
In other words,
when the Apache pod is launched onto a particular Kubernetes node,
that pod can be configured to allow access to any files on that node.
So to restrict this, we need to enable the Pod Security Policy feature.
Now, I've already done this within our demo environment.
Enabling this feature is outside the scope of this course.
However,
you can go to the Pod Security Policy link in the course
notes to get an overview of how this works.
The second step is we need to write a Pod Security Policy.
Makes sense, right?
We will review a Pod Security Policy below.
The Pod Security Policy that you're about to see was
generated by the kubectl advise‑psp command.
Advise‑psp outputs a Pod Security Policy that
allows our current pods to execute.
This is important because it gives us a baseline to start from.
Now let's check out the policy that was generated by advise‑psp.
Note the allowedHostPaths and the hostPath volume.
This allowed the Apache pod access to all files on the Kubernetes node,
which, in turn, allowed the pod access to the registry credentials.
Let's make this Pod Security Policy more granular.
When we enable the Pod Security Policy feature,
the feature will deny anything that is not explicitly
allowed within a Pod Security Policy.
So when we comment out allowedHostPaths and the hostPath volume section,
these privileges will naturally be denied.
Let's see how this works in practice.