Implementing PSPs in Production

Implementing PSPs in Production

Successful PSP implementation requires careful planning and gradual rollout. Organizations should begin by auditing existing workloads to understand current security configurations. This audit reveals which workloads require privileged access, host networking, or other restricted features. Tools like kubectl auth can-i and PSP validation webhooks help identify workloads that would fail under proposed policies.

Creating a PSP hierarchy addresses varying security requirements across workloads. A restrictive baseline policy provides default security for most workloads. Privileged policies accommodate system components requiring elevated access. Mid-tier policies balance security with functionality for specific use cases. This tiered approach maintains security while supporting legitimate requirements.

# Baseline PSP for general workloads
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: 00-baseline
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
  - ALL
  volumes:
  - 'configMap'
  - 'emptyDir'
  - 'projected'
  - 'secret'
  - 'downwardAPI'
  - 'persistentVolumeClaim'
  runAsUser:
    rule: MustRunAsNonRoot
  seLinux:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  readOnlyRootFilesystem: false

---
# Privileged PSP for system components
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: 99-privileged
spec:
  privileged: true
  allowPrivilegeEscalation: true
  allowedCapabilities:
  - '*'
  volumes:
  - '*'
  hostNetwork: true
  hostPorts:
  - min: 0
    max: 65535
  hostIPC: true
  hostPID: true
  runAsUser:
    rule: RunAsAny
  seLinux:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny

Role-Based Access Control (RBAC) integration determines which service accounts can use specific PSPs. This integration requires creating ClusterRoles that grant "use" permissions on PSPs, then binding these roles to appropriate service accounts. Careful RBAC configuration ensures workloads receive only necessary permissions. Default service accounts should bind to restrictive policies, while system components receive specific bindings to privileged policies.