Discuss: Upstream Deprecation of Pod Security Policies

Kubernetes 1.21 is deprecating the PodSecurityPolicy feature (TL;DR: Too complex, too non-obvious, implementation path of PSPs unclear because they fail closed and there's no dry-run). To provide a way to restrict the damage the create verb on pods can do, k8s still wants to deliver a more narrowly scoped solution out of the box. In addition to that, custom admission controllers can be used.

The k8s solution has the working title "PSP Replacement Policy". Roughly speaking, it allows to define one out of three policies on a given namespace: Restricted, Baseline and Unprivileged (gaps are filled in in the KEP). All pods and pod templates will be subject to the defined policies.

This has major implications on Yaook.

As the policy can only be chosen based on the Namespace, we have to slice our project into multiple namespaces in order to be able to have pods with different privileges.

Off the top of my head, we have the following Privileged services:

• nova-compute
• mariadb (for the CAP_SYS_NICE capability)
• neutron-*-agent

I'm not sure about baseline and restricted, but I'd hope that most of our APIs fit into restricted.

This is really unfortunate because we figured in #98 (closed) et al. that we didn't need namespace separation and the major refactor which would be required for this. The good news is that PSP-RP are only due to become alpha for 1.22 and PSPs will continue to function for a while.