Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller
This page describes the process of migrating from PodSecurityPolicies to the built-in PodSecurity admission controller. This can be done effectively using a combination of dry-run and audit and warn modes, although this becomes harder if mutating PSPs are used.
Before you begin
Your Kubernetes server must be at or later than version v1.22. To check the version, enter kubectl version.
Steps
-
Eliminate mutating PodSecurityPolicies, if your cluster has any set up.
- Clone all mutating PSPs into a non-mutating version.
- Update all ClusterRoles authorizing use of those mutating PSPs to also authorize use of the non-mutating variant.
- Watch for Pods using the mutating PSPs and work with code owners to migrate to valid, non-mutating resources.
- Delete mutating PSPs.
-
Select a compatible policy level for each namespace. Analyze existing resources in the namespace to drive this decision.
- Review the requirements of the different Pod Security Standards.
- Evaluate the difference in privileges that would come from disabling the PSP controller.
- In the event that a PodSecurityPolicy falls between two levels, consider:
- Selecting a less permissive PodSecurity level prioritizes security, and may require adjusting workloads to fit within the stricter policy.
- Selecting a more permissive PodSecurity level prioritizes avoiding disrupting or changing workloads, but may allow workload authors in the namespace greater permissions than desired.
-
Apply the selected profiles in
warn and audit mode. This will give you an idea of how your Pods will respond to the new policies, without breaking existing workloads. Iterate on your Pods' configuration until they are in compliance with the selected profiles. - Apply the profiles in
enforce mode. - Stop including
PodSecurityPolicy in the --enable-admission-plugins flag.