Implementing Pod Security Admission Controller

agentic-workflows-blueprint.workflow.implementing-pod-security-admission-controller

Goal

Implement Kubernetes Pod Security Admission (PSA) with controlled policy rollout (audit, warn, enforce) to raise workload security posture without destabilizing operations.

Scope

• Applies to: namespace-level Pod Security Standard enforcement and cluster-level PSA defaults.
• Does not cover: custom policy engines for rules beyond PSA baseline/restricted semantics.

Triggers

• "Enable Pod Security Admission"
• "Migrate from PodSecurityPolicy to PSA"
• "Enforce baseline/restricted policies per namespace"
• "Audit pod security violations before enforcement"

Inputs

• clusterVersion: Kubernetes version and API server config model
• namespacePolicyMap: desired profile per namespace (privileged, baseline, restricted)
• enforcementStrategy: rollout sequence and timing by environment
• exemptionList (optional): system/critical namespaces with justification
• changeWindow (optional): execution window for enforcement changes
• rollbackPlan: policy rollback and emergency exemption procedure

Invariants

• Production namespaces should not jump directly to strict enforcement without audit evidence.
• Enforcement versions must be pinned for deterministic behavior across upgrades.
• Exemptions must be minimal, explicit, and justified.
• Any breaking enforcement change requires rollback readiness before rollout.

Procedure

1. Assess current workload posture

   • Inventory namespace workloads and identify likely PSA violations.
   • If migrating from PSP, map existing controls to PSA profiles.

2. Define target policy map

   • Assign namespace profiles: system namespaces (privileged when justified), staging (baseline), production (restricted target).
   • Define pinned version labels for enforce/audit/warn.

3. Start with audit and warn

   • Apply audit and warn labels before enforce in target namespaces.
   • Collect warning/audit evidence and prioritize remediations.

4. Remediate violating workloads

   • Update securityContext and pod specs to meet target profile.
   • Validate restricted/baseline compliance for critical workloads.

5. Enable enforcement progressively

   • Apply enforce per namespace in staged sequence aligned to changeWindow.
   • Monitor admission rejections and service health after each stage.

6. Configure cluster defaults (optional)

   • When required, configure API server admission control defaults and controlled exemptions.
   • Validate control-plane behavior after config rollout.

7. Verify and stabilize

   • Confirm pod creations match expected allow/deny behavior.
   • Document residual exceptions and follow-up remediation actions.

Outputs

• Namespace PSA label plan and applied label evidence.
• Violation/remediation report from audit and warn phases.
• Enforcement rollout report with accepted/rejected workload outcomes.
• Exemption register with owner, reason, and review date.

Review gate

• Target policy profile per namespace is explicit and version-pinned.
• Audit/warn evidence exists before strict enforcement in sensitive namespaces.
• Violating workloads are remediated or formally excepted.
• Enforcement rollout is staged and operationally validated.
• Exemptions are justified, minimal, and tracked.

References

• ../../SKILL.md
• ../os-platform/SKILL.md
• ../review/SKILL.md
• Interactive HTML View