Full Report
Pod Security Policies were removed in Kubernetes v1.25 — learn how to migrate from Pod Security Policies to Pod Security Standards
Analysis Summary
# Best Practices: Migrating from Kubernetes Pod Security Policies (PSP) to Pod Security Admission (PSA)
## Overview
These practices detail the necessary steps and considerations for migrating Kubernetes security constraints from the deprecated Pod Security Policies (PSP) to the built-in Pod Security Admission (PSA) controller, which enforces Pod Security Standards (PSS). This transition is mandatory as PSPs were removed in Kubernetes v1.25.
## Key Recommendations
### Immediate Actions
1. **Assess Kubernetes Version:** Confirm all clusters are running Kubernetes version 1.25 or later, as PSP functionality is completely removed in this version.
2. **Identify PSP Usage:** Immediately stop relying on PSPs for any new deployments and inventory all namespaces currently utilizing existing PSPs to understand migration complexity.
3. **Evaluate PSA Suitability:** For all new workloads or policy-free namespaces, begin testing the Pod Security Standards (PSS) levels: *Privileged*, *Baseline*, or *Restricted*.
### Short-term Improvements (1-3 months)
1. **Begin Dry-Run Testing:** For namespaces currently without policies, test enforcing PSS levels using the `dry-run=server` flag with `kubectl label`:
bash
$ kubectl label ns <namespace-name> pod-security.kubernetes.io/enforce=<level> --dry-run=server
2. **Remediate Violations:** If dry runs reveal violations, explicitly update the non-compliant pod definitions (or application configurations) to align with the chosen PSS level before permanent enforcement.
3. **Implement PSA Enforcement Labels:** Apply the PSA enforcement label (`pod-security.kubernetes.io/enforce`) to namespaces with simple or no existing PSPs, starting with the least disruptive level (e.g., *Baseline*).
### Long-term Strategy (3+ months)
1. **Develop Tiered Namespace Policies:** Strategically assign PSS levels to namespaces based on their sensitivity (e.g., `kube-system` to *Privileged* or *Baseline*, production apps to *Restricted*).
2. **Address Complex PSPs:** For workloads previously governed by elaborate PSPs that cannot be satisfied by PSS, plan a migration path to a third-party validating admission controller capable of handling complex logic.
3. **Establish Continuous Monitoring:** Integrate security tools (like Wiz or similar scanners) to continuously monitor for namespaces lacking assigned PSA levels or those running at insecure levels (e.g., *Privileged*).
## Implementation Guidance
### For Small Organizations
- **Prioritize Built-in PSA:** Focus solely on migrating to the built-in Pod Security Admission controller, as third-party solutions may introduce unnecessary complexity and cost.
- **Start Simple:** Apply the *Baseline* PSS profile universally to all namespaces as a starting point, then iteratively tighten security for critical applications.
- **Leverage `kubectl` Warnings:** Rely heavily on the output from `kubectl label` commands using `--dry-run=server` to quickly identify and fix non-compliant resource definitions without needing external tooling overhead.
### For Medium Organizations
- **Namespace-Level Control:** Utilize the flexibility of PSA to set differentiated security levels across different application tiers (e.g., development vs. production namespaces).
- **Inventory and Audit:** Conduct an initial audit to categorize existing PSPs (Simple vs. Complex) to manage the migration workload effectively.
- **Phased Rollout:** Roll out PSA enforcement incrementally, starting with non-production environments, before applying stricter policies (like *Restricted*) to sensitive production namespaces.
### For Large Enterprises
- **Multi-Cloud Standardization:** Recognize that Pod Security Standard enforcement may vary across different Cloud Service Providers (CSPs) or Kubernetes flavors (EKS, AKS, GKE); plan for necessary migration process variations per cluster.
- **External Controller for Complexity:** For existing, highly customized PSP logic that exceeds PSS capabilities, proactively select and implement a third-party admission controller solution.
- **Audit RBAC for Policy Modification:** Audit Kubernetes Role-Based Access Control (RBAC) bindings to identify principals (Users/Service Accounts) who possess permission to modify namespace PSA labels (e.g., permissions allowing `namespaces/update` or `namespaces/patch` on `pod-security.kubernetes.io/enforce` labels).
## Configuration Examples
When enforcing PSA, labels are applied to the namespace object:
| Goal | Kubernetes YAML Configuration (Namespace Label) |
| :--- | :--- |
| **Enforce Policy (Active)** | `pod-security.kubernetes.io/enforce: restricted` |
| **Audit Policy (Logging only)** | `pod-security.kubernetes.io/audit: baseline` |
| **Warn on Violation (Notification only)** | `pod-security.kubernetes.io/warn: privileged` |
**Example Dry-Run Command to Test Restricted Policy:**
bash
$ kubectl label ns my-app-namespace pod-security.kubernetes.io/enforce=restricted --dry-run=server
## Compliance Alignment
- **NIST SP 800-204A:** Alignment with securing containerized workloads running in a shared environment.
- **CIS Kubernetes Benchmarks:** PSS maps directly to controlling container runtime behavior, aligning with hardening recommendations for pod execution contexts.
- **ISO/IEC 27001:** Supports the control objective related to managing access control and configuration for execution environments.
## Common Pitfalls to Avoid
- **Assuming Direct Translation:** Do not assume a one-to-one mapping between old PSP rules and the three PSS profiles; complex PSP logic will necessitate external controllers.
- **Ignoring Dry-Run Output:** Failure to act on warnings generated during `--dry-run=server` testing will result in deployment failures once enforcement mode is activated.
- **Delaying Migration:** Given the removal of PSP in v1.25, deferring migration leads to security gaps or platform instability if running unmanaged legacy configurations.
- **Forgetting Audit/Warn Modes:** Only setting the `enforce` label without corresponding `audit` or `warn` labels hinders the ability to safely test policy rollouts and gather visibility into potential configuration drifts.
## Resources
- **Kubernetes Documentation:** Detailed steps for migration and configuration (search for "Pod Security Standards documentation").
- **Wiz Cloud Configuration Rule:** Use built-in rules to proactively identify namespaces lacking any assigned PSP (pre-migration step).
- **Wiz Framework Assessment:** Utilize built-in PSS frameworks within security tools to assess environment readiness without requiring repeated dry runs against the cluster API.