Understanding and Implementing Pod Security Standards (PSS) in K8s

Introduction

As Kubernetes continues to dominate the container orchestration landscape, security remains a critical concern for organizations. Pod Security Standards (PSS) represent a significant evolution in Kubernetes security, providing a standardized approach to securing pod deployments. In this comprehensive guide, we'll explore PSS implementation and best practices that will help you enhance your cluster's security posture.

Prerequisites

A working Kubernetes cluster (version 1.23 or later)
kubectl CLI tool installed
Basic understanding of Kubernetes concepts
Cluster admin access for testing

Understanding Pod Security Standards

The Evolution of Pod Security

Pod Security Standards were introduced as a replacement for the deprecated Pod Security Policies (PSP). While PSPs offered great flexibility, they were often complex to implement and maintain. PSS provides a more streamlined, standardized approach to pod-level security.

The Three Security Levels

PSS defines three distinct security levels, each building upon the previous one:

Privileged (Least Restrictive)
- No restrictions on pod specifications
- Suitable for system and infrastructure workloads
- Should be used sparingly and only when absolutely necessary
Baseline (Minimally Restrictive)
- Prevents known privilege escalations
- Allows default pod configurations
- Suitable for legacy applications and those requiring minimal privileges
Restricted (Highly Restrictive)
- Enforces security best practices
- Implements strong pod hardening
- Recommended for production workloads

PSS Modes of Operation

Each security level can be applied using three different modes:

pod-security.kubernetes.io/enforce: <level>  # Actively blocks violations
pod-security.kubernetes.io/audit: <level>    # Logs violations
pod-security.kubernetes.io/warn: <level>     # Sends warnings to users

Implementing PSS in Your Cluster

1. Namespace Configuration

Let's start by creating a namespace with restricted security standards:

apiVersion: v1
kind: Namespace
metadata:
  name: secure-production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Save this as secure-namespace.yaml and apply:

kubectl apply -f secure-namespace.yaml

2. Deploying a Compliant Application

Here's an example of a security-compliant web application deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-webapp
  namespace: secure-production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: secure-webapp
  template:
    metadata:
      labels:
        app: secure-webapp
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        runAsGroup: 3000
        fsGroup: 2000
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: webapp
        image: nginx:1.21-alpine
        ports:
        - containerPort: 8080
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
          runAsNonRoot: true
          seccompProfile:
            type: RuntimeDefault
        resources:
          limits:
            cpu: "1"
            memory: "512Mi"
          requests:
            cpu: "0.5"
            memory: "256Mi"

3. Validation and Testing

After deploying your application, verify its compliance:

# Check if the pod is running
kubectl get pods -n secure-production

# Describe the pod to verify security contexts
kubectl describe pod <pod-name> -n secure-production

# Check for any PSS violations in the audit logs
kubectl logs -n kube-system <audit-pod-name>

Common Issues and Solutions

Root User Violations

 # Incorrect
 securityContext:
   runAsUser: 0  # Running as root

 # Correct
 securityContext:
   runAsUser: 1000
   runAsNonRoot: true

Privilege Escalation

 # Incorrect
 securityContext:
   allowPrivilegeEscalation: true

 # Correct
 securityContext:
   allowPrivilegeEscalation: false

Missing Security Context Always include both pod-level and container-level security contexts for complete protection.

Best Practices

Start with Audit Mode
- Begin with audit mode to identify potential issues
- Gradually transition to enforce mode
- Monitor for violations before strict enforcement

Use Multiple Modes

 metadata:
   labels:
     pod-security.kubernetes.io/enforce: baseline
     pod-security.kubernetes.io/audit: restricted
     pod-security.kubernetes.io/warn: restricted

Regular Auditing
- Monitor audit logs regularly
- Set up alerts for security violations
- Review and update security policies periodically
Documentation and Training
- Document your security policies
- Train developers on PSS requirements
- Create clear escalation procedures

Monitoring and Observability

Setting up Prometheus Alerts

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: pss-alerts
  namespace: monitoring
spec:
  groups:
  - name: pss.rules
    rules:
    - alert: PodSecurityViolation
      expr: increase(pod_security_violations_total[1h]) > 0
      for: 5m
      labels:
        severity: warning
      annotations:
        description: "Pod security violation detected in namespace {{ $labels.namespace }}"

Conclusion

Pod Security Standards provide a robust framework for securing Kubernetes workloads. By following this guide, you've learned how to:

Understand PSS levels and modes
Implement PSS in your cluster
Deploy secure applications
Monitor and maintain security compliance

Remember that security is an ongoing process. Regularly review and update your security configurations, monitor for violations, and stay informed about new security features and best practices in the Kubernetes ecosystem.

Additional Resources

Did you find this article helpful? Follow me for more Kubernetes and cloud-native security content!

Understanding and Implementing Pod Security Standards (PSS) in Kubernetes