Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller
- Before you begin
- Steps

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 version v1.22. To check the version, enter kubectl version.

Enable the PodSecurity feature gate.

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.