PodSecurityPolicy to Pod Security Admission migration: the short answer
If your cluster still relies on PodSecurityPolicy and must move before an upgrade past 1.24, the move replaces per-policy bindings, which tie a PodSecurityPolicy to users or service accounts through RBAC, with per-namespace labels that enforce the Baseline or Restricted Pod Security Standard. The effort depends mainly on how many of your workloads need privileged settings such as host namespaces, host paths, privileged containers or added Linux capabilities. Each of those either fits Baseline or Restricted or needs a documented exception, so counting them is the first task.
The work itself is a mapping and verification exercise. For each PodSecurityPolicy in use, record what it allowed and denied, decide which Pod Security Standard level covers the same intent, and list the namespaces that will receive the label. Then apply the labels in warn and audit modes to live workloads so violations appear in the output clients see and in your audit logs before anything is blocked. This can run alongside the existing cluster, because running pods do not change until enforcement is turned on. Confirm which Pod Security Admission settings your distribution exposes and how its audit logs are collected.
Timing is set by the upgrade plan, and the policy work alone does not decide it. The migration has to finish on the cluster before the control plane moves past 1.24. The Kubernetes version skew policy requires kube-apiserver to be upgraded one minor version at a time, ahead of the controller manager, scheduler and kubelets, so the upgrade sequence determines when the cluster must be ready. Ask your platform team which release they target, when the first control plane node is upgraded, and who approves the enforcement change in production. Plan a rollback path for any namespace where enforcement breaks a workload.
Three decisions shape the rest of the project and are worth settling early. First, decide whether each namespace targets Baseline or Restricted, and who approves an exception when a workload needs something Restricted forbids. Second, decide who owns namespace labels, so that every new namespace receives a level when it is created. Third, agree how warnings and audit events will be reviewed, because a mode nobody reads offers little protection. Recording these choices in writing gives your auditors and security reviewers something concrete to test later.
What maps cleanly from PodSecurityPolicy and what does not
This table compares each PodSecurityPolicy control with its nearest Pod Security Standards level or Pod Security Admission behavior, and notes where the migration needs another mechanism. Check every mapping against the Pod Security Standards page for your cluster version before you change any namespace label. The main takeaway is that PSA covers the common hardening baseline, but per-workload exceptions and default settings usually need separate work.
| Control | Pod Security Admission equivalent | Migration note |
|---|---|---|
| Privilege escalation | Restricted level requires privilege escalation to be disabled in the pod spec | Maps cleanly. Set allowPrivilegeEscalation to false in workloads before applying Restricted in enforce mode. |
| Host namespaces | Baseline level blocks host network, host PID and host IPC | Maps cleanly for most workloads. Workloads that need host namespaces need a separate exception path or a different design. |
| Host paths | Baseline level blocks hostPath volumes; no path-level allow list exists | No direct equivalent for allowedHostPaths. Confirm which workloads need hostPath, then move them to a supported volume type or an admission policy tool. |
| Capabilities | Baseline allows a default capability set; Restricted requires dropping all and allows only a narrow add list | Partial match. Check requiredDropCapabilities and allowedCapabilities in your policies, since PSA does not let you define custom capability lists. |
| Volume types | Restricted level permits a fixed list of volume types | Partial match. Confirm each volume type your policies allow against the current standard, then handle any others through workload changes. |
| Run-as user and group | Restricted level requires non-root execution; no run-as ranges or fsGroup ranges | No direct equivalent for allowed UID or GID ranges. Set runAsNonRoot and explicit IDs in workloads, and enforce ranges with admission policy tooling if required. |
| Seccomp and AppArmor profiles | Restricted level requires a seccomp profile to be set; Baseline blocks AppArmor unconfined overrides | Partial match. Profile defaults from PSP annotations do not carry over. Set profiles in each workload and confirm AppArmor support on your nodes. |
| RBAC bindings that grant use on policies | No equivalent; PSA uses namespace labels, not a use verb on a policy object | Remove the policy use roles after migration. Control who can change namespace labels with RBAC, since that now sets the enforced level. |
How Pod Security Admission enforces Baseline and Restricted per namespace
Pod Security Admission replaces PodSecurityPolicy with a namespace-scoped model, and the decision that matters most for the migration is how each namespace is labeled. Kubernetes defines three Pod Security Standards: Privileged, which places no restrictions, Baseline, which blocks the best-known privilege escalations, and Restricted, the strictest profile, which adds hardening requirements such as running as non-root. The built-in Pod Security Admission controller evaluates each pod against one of these standards using labels on the namespace it runs in. There is no separate policy object to create, bind or order, so the control point moves from RBAC bindings to namespace metadata.
Each standard can be applied in three modes. Enforce rejects pods that do not comply. Audit allows the pod but records each violation in the audit log. Warn allows the pod and returns a message to the client, such as kubectl, explaining what would fail under enforcement. The labels are set per mode and can target different standards, so a namespace can enforce Baseline while auditing Restricted. Confirm the exact label keys and the version pin option against the Pod Security Standards documentation for the Kubernetes minor version you are running, because the defaults and supported options change across releases.
A staged rollout uses audit and warn first because they reveal which workloads would break without stopping anything. Teams often discover that a Helm chart runs containers as root, mounts host paths or sets privilege escalation, and those findings are only visible when the pod is evaluated. Audit logs must be collected and searchable before the review begins, or the findings are lost. Warn output reaches the person deploying, so it is useful for namespaces with active delivery pipelines. Plan the order: review audit findings per namespace, fix workloads or agree exceptions, then move the enforce label only after a clean period you define.
The team must decide two things before labeling begins. The first is cluster-wide defaults: the admission configuration can set a default level for namespaces without labels, and the choice determines whether an unlabeled namespace is open or constrained after the PodSecurityPolicy objects are removed. Review the default with the platform owner and confirm how it interacts with system namespaces. The second is exemptions. The controller can exempt specific usernames, runtime classes or namespaces from enforcement, and each exemption should have a named owner, a reason and a removal date. Exemptions added during migration tend to become permanent if they are not recorded.
Before changing any label, ask the platform team to export the current PodSecurityPolicy bindings and map each one to the namespace or service account it governs. Then confirm, for every namespace, which standard it needs, which workloads will fail Restricted and whether the owner accepts a Baseline exception. Record these decisions in the migration plan, since the auditors and security reviewers who examine the cluster later will ask why each namespace is labeled as it is.
Documented APIs and export paths for the migration
The Kubernetes documentation provides read-only and dry-run paths to size the move before anything is enforced. No supplied, documented converter turns PodSecurityPolicy objects into Pod Security Admission labels, so mapping each policy to a Baseline or Restricted level is a reviewed, manual exercise. The cards below cover what to inventory, how to apply labels, and where to find violations.
Inventory PodSecurityPolicy objects and bindings
List every PodSecurityPolicy object in the cluster, then find the Roles, ClusterRoles, RoleBindings and ClusterRoleBindings that grant the use verb on those policies. These bindings show which service accounts and users depend on each policy. A policy with no bindings is a candidate for retirement, while a bound policy needs a reviewed replacement before the upgrade. Confirm the policy API group and version that your target cluster still serves in the Kubernetes documentation for that release.
Apply namespace labels for each mode
Pod Security Admission reads labels on namespaces. Each namespace can set enforce, audit and warn modes, each with a level of baseline or restricted and an optional version pin. Plan the three modes separately: enforce blocks non-compliant pods, while audit and warn let you observe impact first. Confirm the exact label keys, the accepted level values and the version pin syntax in the Pod Security Standards documentation for your target version.
Surface violations with server-side dry run
Before enforcing, apply the namespace label with a server-side dry run so the API server evaluates existing workloads without changing them. Violations come back as warnings in the response, which you capture for each namespace. Check that the warnings also cover controllers such as Deployments and StatefulSets, since their pod templates are evaluated too. Confirm how your kubectl and server versions return these warnings and what the dry-run flag accepts in your release.
Read audit logs for audit-mode violations
Audit mode records violations in the kube-apiserver audit log without rejecting pods, so the log is the main source for workloads that create pods at runtime, such as Jobs and operator-managed resources. The log only carries these annotations if the audit policy captures the relevant request levels and stages, so check that policy on your cluster first. Filter for pod security annotations per namespace, and set log retention long enough to cover your normal deployment cadence. Confirm the annotation keys and audit policy fields in the audit documentation for your version.
Configure cluster-wide defaults where supported
The Pod Security Admission controller can read a cluster-wide configuration file that sets default enforce, audit and warn levels for namespaces without labels. The same file can list exempt namespaces, usernames or runtime classes. Use it to set a safe baseline while teams migrate, and keep exemptions limited to system namespaces whose workloads cannot meet the standard. Confirm that your target version supports this configuration format, how your distribution passes the file to kube-apiserver, and which fields the admission configuration reference defines for that release.
The PodSecurityPolicy to Pod Security Admission migration sequence with parallel run and cutover
This sequence moves each namespace from PodSecurityPolicy to Pod Security Admission without a gap in admission control. A parallel run with both controllers active surfaces findings before enforcement changes, and PodSecurityPolicy objects are removed only after the cluster runs clean and the upgrade path is confirmed.
Inventory policies, bindings and dependent workloads
The platform team lists every PodSecurityPolicy object, each ClusterRole and RoleBinding that grants the use verb on a policy, and the namespaces and service accounts that depend on them. Workload owners confirm which applications need privileged, host-networked or root-level containers. This step is read-only, so it can start immediately and run alongside the standards mapping. It is done when one inventory lists each policy, each binding and each namespace with a named owner, and the team has checked the policy recorded on running pods against that list. Confirm the exact RBAC verbs and pod annotations your version uses.
Back up etcd and record cluster state
Before any label or policy change, the operator takes an etcd snapshot with etcdctl snapshot save, verifies it, and stores it outside the cluster. The team also exports the PodSecurityPolicy objects, RBAC bindings, namespace labels, and the current kube-apiserver version and flags. This step must finish before any enforcement change, because every later step depends on a known state to return to. It is done when the snapshot passes verification, the exports are committed to version control, and someone other than the operator has read the restore procedure, which uses etcdutl. Where possible, test the restore in a non-production cluster first.
Map workloads to standards and exemptions
Each workload class is assigned to Privileged, Baseline or Restricted, starting from the policy that class currently receives. Pods that need capabilities Baseline does not allow are listed as exemptions, each with a named owner, a stated reason and a review date. Security and workload owners sign the mapping together, and exemptions are recorded in writing before any namespace is labeled. This step can run in parallel with the inventory, since both feed the same table. It is done when every namespace has a target level, every exemption has an approver, and the signed document is stored with the backup record. Confirm how your version applies exemptions for namespaces, users and service accounts.
Label a pilot namespace in audit and warn
The team picks one low-risk namespace and sets the audit and warn labels to the target level, leaving the enforce label unset. Warnings appear for client applies and audit events are written to the API server audit log, while PodSecurityPolicy continues to decide admission. The workload owner and platform team review each finding together and either fix the workload or move it to the agreed exemption list. This step waits for the backup and the signed mapping. It is done when the pilot shows no unresolved findings and the owner accepts the result in writing. Confirm which audit and warn level values your version accepts.
Widen audit and warn across all namespaces
The same labels are applied to the remaining namespaces in batches, each batch set to its agreed target level. PodSecurityPolicy stays active throughout, so it still admits pods while the new controller reports what it would reject. Findings from warnings and the audit log are collected into one list per owner, and each finding is fixed, exempted or accepted. The parallel run ends when a full review cycle shows no unexpected findings. It is done when every namespace carries audit and warn labels, the findings list is empty or fully exempted, and each owner has signed off. Confirm how long your audit log retains events so the review window is covered.
Switch to enforce namespace by namespace
Namespaces move to enforce one at a time, starting with the lowest-risk and finishing with those carrying the most exemptions. After each change, the team deploys a test pod that should be rejected and one that should be admitted, then watches the namespace for unexpected rejected rollouts. Rollback is removing the enforce label, which the team tests on the pilot namespace first. While both controllers are active, a pod must satisfy each one that applies, so the team confirms that PodSecurityPolicy does not admit anything Pod Security Admission rejects. It is done when every namespace enforces its target level and no unplanned rejections remain.
Remove PodSecurityPolicy after a clean run
Only after the parallel run is clean, the team deletes the PodSecurityPolicy objects and the RBAC bindings that granted their use. The PodSecurityPolicy admission plugin is then removed from the API server configuration. This is a change to a live control plane, so it waits for the upgrade window and for a fresh etcd snapshot taken immediately before the change. It is done when no PodSecurityPolicy objects or bindings remain, the API server starts without the plugin, and the audit log shows Pod Security Admission decisions for every namespace. Confirm the removal steps for your distribution, since some manage API server flags for you.
Confirm the upgrade path with version skew rules
Before the next minor upgrade, the team reads the Kubernetes version skew policy. kube-apiserver is upgraded one minor version at a time, followed by kube-controller-manager, kube-scheduler and kubelets, and kubelets may be up to three minor versions older than kube-apiserver. The team confirms that each target version still receives patches on the release support page and that every component on the path is covered by the plan. This step waits for the removal to finish and for an approved upgrade window. It is done when a written plan lists each minor step with its backup point and rollback, and the team has confirmed Pod Security Admission behavior for every version on the path.
What drives the cost and duration of the migration
This table lists the factors that move the effort and calendar time of a PodSecurityPolicy to Pod Security Admission migration, with the effect of each on cost and schedule. Use it to see which parts of your estate will expand the work and what to name in a written scope before comparing quotes.
| Driver | Effect on cost and schedule | What to request in a quote |
|---|---|---|
| Number of namespaces and clusters | Each namespace needs its own labels, warn and audit decisions, and testing. Effort grows with every cluster that has its own policy set. | A per-cluster and per-namespace inventory, and whether the work covers every cluster or a defined subset |
| Count of PodSecurityPolicy objects and bindings | More policies and RoleBinding or ClusterRoleBinding links mean more mapping decisions and more ways for a workload to pass or fail the new standards. | A mapping table from each PSP and binding to a target standard, with the owner who signs off each mapping |
| Workloads that need privileged containers | Privileged workloads often sit outside Baseline and Restricted and need an exemption, a redesign or a documented risk acceptance. Each one adds design and review time. | A list of privileged workloads, the proposed handling for each, and who approves exceptions |
| Host networking, host paths and added capabilities | These settings fail Baseline checks and usually require owner input to remove or justify. Workloads that use them tend to take the longest to test. | A count of workloads using hostNetwork, hostPath or added capabilities, and the expected changes or exemptions |
| Number of teams that own workloads | Each owning team must review its namespaces, fix manifests and confirm test results. Coordination time often exceeds technical change time. | Named owners per namespace, and whether the provider runs the coordination or the client team does |
| Existing audit log pipeline | If audit logs already reach a central system, warn and audit results can be reviewed sooner. Without it, a log collection step is added before enforcement decisions can be made. | Confirmation of current audit log destinations, retention and access, and whether new collection is in scope |
| Change control and maintenance windows | Required approvals, change tickets and limited windows lengthen the calendar even when the technical work is small. Rollbacks may need a rehearsed plan. | The change calendar, approval steps, and the number of windows the plan assumes |
| High availability and etcd backups | A highly available control plane with a tested etcd backup lowers the risk of rollout changes. Without one, the plan needs a backup and restore check before any enforcement change. | Whether etcd backups are current and tested, and whether a pre-change backup is included in scope |
| Air-gapped operation and private registry | Clusters without internet access need image mirroring and registry access checks before tests run. Image pull problems during validation can add days of troubleshooting. | Confirmation of the private registry, how images reach the cluster, and who approves mirroring |
What usually goes wrong when PodSecurityPolicy is removed
Each risk below comes from a step that looks routine during a PodSecurityPolicy migration. For each one, the card gives the prevention step and a check that shows the step worked, such as a server-side dry run, an audit review or a restore test. Work through them in order, because the backup and dry-run checks should pass before any namespace moves to enforce.
Restricted enforced on system namespaces
Setting enforce to Restricted on kube-system or on namespaces that run privileged agents blocks their pods at the next rollout, which may happen outside business hours. Start every namespace in warn and audit mode, and move to enforce only after a server-side dry run reports no violations. Check: apply the label with kubectl in dry-run mode set to server, review the returned warnings, and confirm the system DaemonSets reschedule cleanly in staging.
RBAC bindings left on removed policies
Roles and ClusterRoles that grant the use verb on policy resources keep existing after the policy objects are gone, and service accounts bound to them can mislead later audits and troubleshooting. Before removing anything, list every RoleBinding and ClusterRoleBinding that references those roles and record which service accounts depend on them. Check: after cleanup, run kubectl auth can-i with impersonation for those service accounts and confirm no remaining role grants the use verb on policy resources.
Warnings nobody reads
Warn mode prints messages to the client that applied a manifest, and audit mode writes annotations to the audit log, so neither changes behavior until someone acts on it. Teams often treat a clean deployment as proof of readiness when violations were only logged. Assign an owner to the audit stream, route entries to a searchable store, and review them on a fixed schedule. Check: deploy a test pod with a deliberate violation into a labeled namespace and confirm the entry reaches the owner's queue.
Missing exemptions for node agents
CNI plugins, storage drivers, log shippers and node exporters often need host namespaces, host paths or privileged containers, and Restricted forbids all of them. Inventory every DaemonSet and static pod by the privileges it requests, then decide whether each one runs in a namespace at the Privileged level or is covered by an exemption in the admission configuration. Check: after the change, confirm each node agent runs on every node and that monitoring still shows data from every node.
Skipping the etcd backup
Namespace labels, RBAC changes and control plane upgrades all write to etcd, and Secrets are stored unencrypted there by default, so a bad change can be hard to reverse by hand. Take a snapshot with etcdctl snapshot save from a healthy member before the first change, and store it outside the cluster. Check: restore the snapshot with etcdutl into a separate environment and confirm the API server starts and existing objects are present. A backup that has never been restored is untested.
Upgrading before workloads are cleared
Once the control plane moves past the 1.24 boundary this migration targets, workloads that depended on policy objects lose the protections they assumed, and failures can look like unrelated errors. Gate the control plane upgrade on a written checklist: no workloads depend on policies, every namespace carries its intended labels, and the backup has been restored. Follow the version skew policy by upgrading kube-apiserver first, one minor version at a time. Check: list pods and controllers across namespaces in staging and confirm each is admitted under the new standards.
What the work needs from your team and what you receive
The migration moves faster and with fewer surprises when your team commits people and access before the first assessment starts. Four client inputs matter most. First, cluster access and change windows: the work needs admin access to the affected clusters, including read access to the namespaces, and dated windows where label changes and workload restarts can happen. Second, an inventory owner, one named person who answers for the list of namespaces, workloads and service accounts in scope and who signs off when the list is complete. Without that owner, unlabeled namespaces tend to be found during an upgrade instead of before it.
Third, named workload owners for each namespace. Pod Security Admission applies a level per namespace, so a namespace that moves from Privileged to Baseline or Restricted changes how its own pods are admitted. The workload owner confirms which pods need host networking, host paths, privilege escalation or extra capabilities, and says whether the team can change those settings or needs an exemption. Fourth, the current PodSecurityPolicy and RBAC manifests, including the policies, ClusterRoles, RoleBindings and the service accounts that use the use verb on each policy. The mapping decisions depend on these files, not on memory of how the policies were meant to work.
Fifth, audit log access. The verification plan uses the audit and warn modes on namespace labels to show which pods would be rejected before enforcement is turned on, and your team needs read access to the API server audit logs and to the warning output from deployment tools during that period. Sixth, sign-off on exemptions. Any workload that stays at a weaker level, or any service account exempted from admission, needs a named approver, a reason and a review date recorded in the scope document. Ask who in your organization holds that authority before the work begins.
In return, the partner delivers under a written scope: a namespace and workload inventory, the mapping decisions for each policy, the namespace label configuration as applied manifests, verification evidence from audit and warn runs, runbooks for the enforcement change and for rollback, and handover notes for the platform team. DeployOpen prepares these controls and this evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so ask your assessor early which artifacts they expect to see and include them in the scope.
Questions teams ask before migrating from PodSecurityPolicy
What does a PodSecurityPolicy to Pod Security Admission migration cost?
Cost depends on how many namespaces, workloads and PodSecurityPolicy objects you must review, and on how many workloads need manifest changes. Most of the spend is labor: inventorying which policies bind to which service accounts through RBAC, mapping each policy to a Pod Security Standard, testing workloads that fail the target level, changing manifests and running the cutover. A partner is paid for the scoped work, while your own engineers and application owners carry a time cost that a quote will not show. Recurring costs are small: keeping namespace labels in version control and reviewing audit and warning output after each change. To compare quotes, ask for each phase priced separately, workload remediation grouped by namespace, rehearsal work on a non-production cluster, handover documentation, and an explicit list of exclusions such as application code changes or the Kubernetes upgrade itself.
How long does the migration take, and what sets the timing?
The deadline is set by your upgrade plan. PodSecurityPolicy has to be replaced before you upgrade past 1.24, so the work must finish ahead of the first cluster upgrade step that crosses that boundary. The Kubernetes version skew policy also requires control plane components to move one minor version at a time, so each upgrade step needs its own window. Duration depends on the number of namespaces, the count of workloads that need privileged or host-level settings, how quickly application owners approve changes, and whether you rehearse on a non-production cluster first. Confirm the target version's documentation for the exact PodSecurityPolicy removal behavior before you set dates. Ask any quote for a schedule tied to your upgrade windows, with named dependencies on application owners and change approvers.
What must our team provide before the migration starts?
The engagement needs read access to the clusters and a clear picture of what runs in them. Typical inputs are a read-only kubeconfig or RBAC role for inventory, exported PodSecurityPolicy objects, the RoleBindings and ClusterRoleBindings that reference them, and a list of namespaces with a named owner for each. Also provide workload manifests or Helm charts stored in version control, any existing audit or warning logs, the target Kubernetes version and your upgrade calendar, a non-production cluster for rehearsal, change windows, and a sign-off contact for security exceptions. Name the people who can decide on privileged workloads. Missing ownership data tends to stall discovery, so ask the quote to state which inputs are assumed and who supplies each one.
Can an internal platform team complete this migration on its own?
Yes, many teams can, if they have engineers who read pod specs fluently, understand RBAC bindings and can keep application owners engaged for the length of the work. The task is mostly inventory, manifest change and verification, and less about new platform design, so the skills gap is usually narrower than for a full cluster build. A partner adds value when the internal team lacks spare capacity before the upgrade deadline, needs a second reviewer for privileged exceptions, or wants a documented method it can reuse across many clusters. DeployOpen plans, implements, documents and hands over this kind of work in infrastructure you control, under a written, fixed scope agreed before work starts. Assess your team's gaps against the Pod Security Standards documentation and the skills your upgrade plan already requires.
Does Pod Security Admission cover every PodSecurityPolicy control?
No. Pod Security Admission enforces three predefined Pod Security Standards (Privileged, Baseline and Restricted) per namespace, and it does not reproduce every field PodSecurityPolicy could set. PodSecurityPolicy let administrators define custom rules for volume types, allowed host paths, user and group ranges and other settings, then bind them to specific accounts. Those fine-grained rules have no one-to-one equivalent, so each policy must be compared field by field with the standard levels. Anything the standards do not express needs another mechanism, such as a policy engine or a validating admission webhook, which is a design decision with its own maintenance cost. Check the current Pod Security Standards page and the documentation for your target version before you record a field as covered.
What happens to workloads that need privileged settings after the switch?
They are either placed in a namespace at the Privileged level or exempted, and each choice should be recorded. Pod Security Admission applies the level set by namespace labels, and its admission configuration can exempt specific users, runtime classes or namespaces from enforcement. Treat exemptions as exceptions: keep a register that names the workload, its owner, the justification, the narrowest setting that works and a review date. Where possible, reduce the need first, for example by dropping added capabilities or replacing a host path mount with a supported volume type. Audit and warn modes show which workloads would fail before enforcement starts, which gives owners time to respond. Confirm the exemption fields and label syntax in the documentation for your target version before you write the configuration.
Does this migration change our compliance status?
No. Replacing PodSecurityPolicy changes how one control is implemented, but it does not by itself make a cluster compliant or audited. DeployOpen prepares systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue any reports or attestations. Useful evidence includes the namespace label configuration in version control, RBAC changes, the exception register, audit log samples and test results from the rehearsal. Map these to the framework your assessor uses, since that framework's requirement wording and scope decide what counts. The CIS Kubernetes Benchmark is a common reference for pod security settings, and its recommendations vary by distribution and managed service, so confirm with your assessor which ones apply to your cluster and version.
How DeployOpen works on this
DeployOpen treats the move from PodSecurityPolicy to Pod Security Admission as a planned change to your own clusters, not a configuration swap. We start from an inventory of what each existing policy allows, map it to the Baseline and Restricted Pod Security Standards, and roll enforcement out namespace by namespace in audit and warn modes before anything is blocked.
How we scope
- Inventory every PodSecurityPolicy object, its bindings through RBAC, and the namespaces and workloads it governs.
- Agree in writing which namespaces move to Baseline or Restricted and which exceptions need documented justification.
- Confirm the Kubernetes version you upgrade to, since PodSecurityPolicy must be removed before upgrading past 1.24.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed before work starts; ongoing support is available as a retainer.
How we build
- Map each PodSecurityPolicy control to the Pod Security Standards, noting where a policy setting has no direct equivalent.
- Apply namespace labels in audit and warn modes first, then review the logged violations with the workload owners.
- Fix or formally exempt non-compliant workloads, such as privileged DaemonSets, before switching enforcement on.
- Test enforcement in a non-production cluster that matches your admission setup and confirm the results before production.
How we hand over
- Deliver a mapping document showing each former policy, its replacement standard and the namespaces it now covers.
- Document the namespace label configuration, the audit and warn settings and the exception register with owners and review dates.
- Provide runbooks for adding a new namespace, handling a blocked deployment and removing the old PodSecurityPolicy resources.
- Walk your platform and security teams through the evidence so they can repeat the process for future clusters.
How we support
- Review admission violations and new exceptions as your workloads change, through an optional retainer.
- Re-check namespace labels and standard levels alongside each Kubernetes minor version upgrade in your plan.
- Confirm with your team which Pod Security Admission behavior and cluster version you run before each change.
- Keep the exception register current so audit findings can be answered from documented decisions.
