Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller [page]deterministic

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.

##

If you are currently running a version of Kubernetes other than , you may want to switch to viewing this page in the documentation for the version of Kubernetes that you are actually running.

This page assumes you are already familiar with the basic [Pod Security Admission](/docs/concepts/security/pod-security-admission/) concepts.

## Overall approach

There are multiple strategies you can take for migrating from PodSecurityPolicy to Pod Security Admission. The following steps are one possible migration path, with a goal of minimizing both the risks of a production outage and of a security gap.

0. Decide whether Pod Security Admission is the right fit for your use case. 1. Review namespace permissions 2. Simplify & standardize PodSecurityPolicies 3. Update namespaces 1. Identify an appropriate Pod Security level 2. Verify the Pod Security level 3. Enforce the Pod Security level 4. Bypass PodSecurityPolicy 4. Review namespace creation processes 5. Disable PodSecurityPolicy

## 0. Decide whether Pod Security Admission is right for you {#is-psa-right-for-you}

Pod Security Admission was designed to meet the most common security needs out of the box, and to provide a standard set of security levels across clusters. However, it is less flexible than PodSecurityPolicy. Notably, the following features are supported by PodSecurityPolicy but not Pod Security Admission:

• Setting default security constraints - Pod Security Admission is a non-mutating admission controller, meaning it won't modify pods before validating them. If you were relying on this aspect of PSP, you will need to either modify your workloads to meet the Pod Security constraints, or use a [Mutating Admission Webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) to make those changes. See [Simplify & Standardize PodSecurityPolicies](#simplify-psps) below for more detail.
• Fine-grained control over policy definition - Pod Security Admission only supports [3 standard levels](/docs/concepts/security/pod-security-standards/). If you require more control over specific constraints, then you will need to use a [Validating Admission Webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) to enforce those policies.
• Sub-namespace policy granularity - PodSecurityPolicy lets you bind different policies to different Service Accounts or users, even within a single namespace. This approach has many pitfalls and is not recommended, but if you require this feature anyway you will need to use a 3rd party webhook instead. The exception to this is if you only need to completely exempt specific users or [RuntimeClasses](/docs/concepts/containers/runtime-class/), in which case Pod Security Admission does expose some [static configuration for exemptions](/docs/concepts/security/pod-security-admission/#exemptions).

Even if Pod Security Admission does not meet all of your needs it was designed to be _complementary_ to other policy enforcement mechanisms, and can provide a useful fallback running alongside other admission webhooks.

## 1. Review namespace permissions {#review-namespace-permissions}

Pod Security Admission is controlled by [labels on namespaces](/docs/concepts/security/pod-security-admission/#pod-security-admission-labels-for-namespaces). This means that anyone who can update (or patch or create) a namespace can also modify the Pod Security level for that namespace, which could be used to bypass a more restrictive policy. Before proceeding, ensure that only trusted, privileged users have these namespace permissions. It is not recommended to grant these powerful permissions to users that shouldn't h …(trimmed)