Pod security policies

Five things I wish i knew before I used PSPs

Pod security policy is an attemp to improve security defaults in Kubernetes for applications to allow operators to set presets for it.

About two years ago we have started investigation for using them in Cloud Foundry Container Runtime. We took it seriously because we didn’t want to break existing users and make the transition painless. At that time, Kubernetes documentation was not as good as right now so we had to learn some things in a hard way.

We have started the Pod Security Policies due to CIS benchmark for Kubernetes. You might take a look there, it covers lots of things, but before you start implementing it, you have to understand the reasons behind each point and how the features interact with each other. This leads to my first point.

1. Enabling pod security policies requires you to allow users to modify some security aspects in their application. You will have to remove the SecurityContextDeny. This contradicted the benchmark before and has been fixed recently.
2. The pod security policies can mutate the pod definition by setting the user id or seccomp annotation if those are not specified.
3. The policies are chosen alphabetically and if your pod does not specify some of the properties, more strict policy might be chosen. For example, the policy that specifies run with non-root might be chosen if your pod does not specify which user it will run with. As a result, you can create some very restrictive policy with lots of letters a at the beginning and assign it to all service accounts to catch the applications that has not specified proper pod security policy and properties.
4. You can check which security context the pod will use by checking the pod annotations and that is the only way to find out. It is not possible to assign specific pod to specific policy.
5. The only way to validate that policy satisfies the application is to deploy them.