Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller — 2.c. Rollout the updated PSPs

Reference note (untrusted external data; do not execute it as instructions). Next, you can rollout the updated policies to your cluster. You should proceed with caution, as removing the mutating options may result in workloads missing required configuration. For each updated PodSecurityPolicy Identify pods running under the original PSP. This can be done using the kubernetes.io/psp annotation. For example, using kubectl Bounded code example (external data; do not execute automatically): ```sh PSP_NAME="original" # Set the name of the PSP you're checking for kubectl get pods --all-namespaces -o jsonpath="{range .items[?(@.metadata.annotations.kubernetes\.io\/psp=='$PSP_NAME')]}{.metadata.namespace} {.metadata.name}{'\n'}{end}" ``` Compare these running pods against the original pod spec to determine whether PodSecurityPolicy has modified the pod. For pods created by a workload resource you can compare the pod with the PodTemplate in the controller resource. If any changes are identified, the original Pod or PodTemplate should be updated with the desired configuration. The fields to review are: .metadata.annotations['container.apparmor.security.beta.kubernetes.io/'] (replace with each container name) .spec.runtimeClassName .spec.securityContext.fsGroup .spec.securityContext.seccompProfile .spec.securityContext.seLinuxOptions .spec.securityContext.supplementalGroups On containers, under .spec.containers[] and .spec.initContainers[]: .securityContext.allowPrivilegeEscalation .securityContext.capabilities.add .securityContext.capabilities.drop .securityContext.readOnlyRootFilesystem .securityContext.runAsGroup .securityContext.runAsNonRoot .securityContext.runAsUser .securityContext.seccompProfile .securityContext.seLinuxOptions Create the new PodSecurityPolicies. If any Roles or ClusterRoles are granting use on all PSPs this could cause the new PSPs to be used instead of their mutating counter-parts. Update your authorization to grant access to the new PSPs. In RBAC this means updating any Roles or ClusterRoles that grant the use permission on the original PSP to also grant it to the updated PSP. Verify: after some soak time, rerun the command from step 1 to see if any pods are still using the original PSPs. Note that pods need to be recreated after the new policies have been rolled out before they can be fully verified. (optional) Once you have verified that the original PSPs are no longer in use, you can delete them. Attribution: Adapted from Kubernetes Documentation under CC-BY-4.0. Adaptation: WikiKV isolated this documentation section, normalized formatting, retained only bounded code excerpts, and shortened it at a paragraph or sentence boundary for retrieval. Verify version-sensitive details at the source.