Pod Security Policies (PSP) in DevSecOps: A Comprehensive Tutorial

Introduction & Overview

Pod Security Policies (PSP) are a critical Kubernetes feature for enforcing security constraints on pods, aligning seamlessly with DevSecOps principles of integrating security into development and operations. This tutorial provides an in-depth exploration of PSP, covering its concepts, setup, real-world applications, and best practices, tailored for DevSecOps practitioners.

What is Pod Security Policies (PSP)?

Pod Security Policies are Kubernetes cluster-level resources that define security-related conditions pods must meet to be accepted by the cluster. They control aspects like privilege escalation, container capabilities, and user permissions, ensuring workloads adhere to organizational security standards.

History or Background

Introduced in Kubernetes 1.3 (2016), PSPs evolved to address the need for fine-grained security controls in containerized environments. They were deprecated in Kubernetes 1.21 (2021) and removed in 1.25 (2022), replaced by Pod Security Standards (PSS) and alternatives like Open Policy Agent (OPA). This tutorial focuses on PSPs for legacy systems and their relevance in DevSecOps.

Why is it Relevant in DevSecOps?

In DevSecOps, security is embedded throughout the software development lifecycle (SDLC). PSPs contribute by:

• Enforcing Security Early: Preventing insecure pod configurations during deployment.
• Automating Compliance: Aligning with standards like CIS Benchmarks or NIST.
• Reducing Attack Surface: Limiting privileges to minimize risks in containerized workloads.

Core Concepts & Terminology

Key Terms and Definitions

• Pod: The smallest deployable unit in Kubernetes, consisting of one or more containers.
• Pod Security Policy: A cluster-level resource defining security constraints for pods.
• RBAC: Role-Based Access Control, used alongside PSP to manage permissions.
• Security Context: Pod or container-level settings for security (e.g., user IDs).
• Admission Controller: Kubernetes component that enforces PSPs during pod creation.

Term	Description
PSP	A Kubernetes resource defining security policies for pod creation.
Security Context	Pod-level setting defining privileges and access controls.
Admission Controller	Kubernetes component that enforces PSPs on pod requests.
RunAsUser	Specifies the user ID under which the container runs.
SELinuxOptions	Defines SELinux labels for access control.
Capabilities	Linux capabilities that can be added/dropped in containers.

How It Fits into the DevSecOps Lifecycle

PSPs integrate into the DevSecOps lifecycle by:

• Build Phase: Ensuring container images adhere to security baselines.
• Deploy Phase: Validating pod configurations via admission controllers.
• Run Phase: Monitoring and auditing running pods for compliance.

DevSecOps Stage	PSP Role
Plan	Define security policies for pods aligned with org policies
Develop	Educate developers on security requirements enforced by PSP
Build	Validate images and configurations that will comply with PSP
Test	Use admission policies to catch security misconfigurations early
Release	Enforce consistent runtime security rules across environments
Deploy	Block non-compliant pods from running
Operate	Monitor policy violations and update policies for evolving threats

Architecture & How It Works

Components and Internal Workflow

PSPs operate through Kubernetes’ admission control mechanism. Key components include:

• PSP Resource: Defines rules (e.g., privileged: false, runAsUser).
• Admission Controller: Enforces PSP rules during pod creation or update.
• RBAC Integration: Links PSPs to users or service accounts via roles.

The workflow is:

1. A user submits a pod creation request.
2. The Kubernetes API server invokes the PSP admission controller.
3. The controller validates the pod against applicable PSPs.
4. If compliant, the pod is created; otherwise, it’s rejected.

Architecture Diagram Description

Visualize a flowchart with:

• A user submitting a pod manifest to the Kubernetes API Server.
• The API Server forwarding the request to the PSP Admission Controller.
• The controller checking the pod against PSP rules (stored in etcd).
• Arrows showing approval (to pod creation) or rejection (error to user).
• RBAC roles linking users to PSPs.

[ Developer/User ]
        ↓
   [ kubectl apply ]
        ↓
[ Kubernetes API Server ]
        ↓
[ Admission Controller (PSP) ]
        ↓       ↘
 [ Valid PSP ]   [ Rejected ]
        ↓
   [ Pod Scheduled ]

Integration Points with CI/CD or Cloud Tools

PSPs integrate with:

• CI/CD Pipelines: Tools like Jenkins or GitLab CI validate pod specs before deployment.
• Cloud Tools: AWS EKS, GCP GKE, or Azure AKS enable PSPs via cluster configurations.
• Monitoring Tools: Prometheus or Grafana track PSP violations.

Installation & Getting Started

Basic Setup or Prerequisites

• Kubernetes cluster (v1.21 or earlier for PSP support).
• kubectl configured with cluster admin access.
• RBAC enabled in the cluster.

Hands-On: Step-by-Step Beginner-Friendly Setup Guide

1. **Enable PSPthernet:
   • Edit the API server configuration (e.g., /etc/kubernetes/manifests/kube-apiserver.yaml).
   • Add --enable-admission-plugins=PodSecurityPolicy to the kube-apiserver flags.
   • Restart the API server.
2. Create a PSP:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted-psp
spec:
  privileged: false
  runAsUser:
    rule: MustRunAsNonRoot
  seLinux:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
    - 'configMap'
    - 'secret'

3. Apply the PSP:

kubectl apply -f restricted-psp.yaml

4. Link PSP to RBAC:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: use-restricted-psp
rules:
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs: ['use']
  resourceNames: ['restricted-psp']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: restricted-psp-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: use-restricted-psp
subjects:
- kind: ServiceAccount
  name: default
  namespace: default

5. Test a Pod:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: nginx
    image: nginx

Apply and verify if the pod complies with the PSP.

Real-World Use Cases

• Financial Services: A bank uses PSPs to ensure containers run as non-root users, preventing privilege escalation in payment processing apps.
• Healthcare: A hospital enforces PSPs to restrict volume mounts, ensuring HIPAA compliance for patient data workloads.
• E-commerce: An online retailer uses PSPs to limit network policies, reducing risks of data breaches in customer-facing apps.
• CI/CD Pipelines: A DevSecOps team integrates PSP validation in GitLab CI to catch insecure pod configurations pre-deployment.

Benefits & Limitations

Key Advantages

• Granular control over pod security settings.
• Seamless integration with Kubernetes RBAC.
• Enhances compliance with industry standards.

Common Challenges or Limitations

• Deprecated in Kubernetes 1.21; not supported in newer clusters.
• Complex RBAC setup can lead to misconfigurations.
• Limited flexibility compared to modern alternatives like OPA.

Best Practices & Recommendations

• Security: Use restrictive PSPs by default; allow exceptions via RBAC.
• Performance: Minimize PSP complexity to reduce admission controller overhead.
• Maintenance: Regularly audit PSPs and RBAC bindings for compliance.
• Compliance: Align PSPs with CIS Kubernetes Benchmarks.
• Automation: Use tools like Terraform to manage PSP configurations.

Comparison with Alternatives

Feature	PSP	Pod Security Standards (PSS)	OPA/Gatekeeper
Granularity	High (pod-level controls)	Medium (baseline, restricted, privileged)	Very high (custom policies)
Ease of Use	Complex RBAC setup	Simple, built-in	Moderate, requires policy authoring
Kubernetes Support	Deprecated (1.21+)	Native (1.21+)	External, ongoing support
Flexibility	Limited to pod settings	Predefined profiles	Highly customizable

When to Choose PSP

Use PSPs for:

• Legacy Kubernetes clusters (pre-1.25).
• Environments requiring strict pod-level security without external tools.

Choose alternatives like PSS or OPA for modern clusters or complex policy needs.

Conclusion

Pod Security Policies remain a valuable tool for securing Kubernetes workloads in legacy environments, offering granular control and DevSecOps alignment. While deprecated, their principles inform modern solutions like PSS and OPA. Future trends point to policy-as-code approaches for enhanced flexibility. For next steps, explore PSP setups in test clusters or transition to PSS for newer Kubernetes versions.