Securing Kubernetes With Pod Security Standards

• 20/2/2024
• 4-minute read

With the widespread adoption of Kubernetes for orchestrating containerized applications, securing these workloads has become increasingly critical. One of the most significant security improvements in recent Kubernetes releases is the introduction of Pod Security Standards (PSS), which replaced the deprecated Pod Security Policies (PSP). This transition represents a more flexible, namespace-oriented approach to securing your Kubernetes environment. In this article, we’ll explore how Pod Security Standards work, why they matter, and how to implement them effectively in your clusters.

Understanding Pod Security Standards

Pod Security Standards define three different security profiles that provide increasing levels of restriction on Pod specifications:

The Three Security Profiles

The Pod Security Standards implementation in Kubernetes consists of two main components:

1. Pod Security Admission Controller: Built into Kubernetes API server (enabled by default since v1.25)
2. Namespace Labels: Used to configure which security standards apply to each namespace

The Problem: Container Escape Risks

Containers by themselves provide weak isolation. Without proper security constraints, attackers who compromise a container can potentially:

• Escape to the host system
• Access sensitive node resources
• Move laterally within the cluster
• Compromise other workloads

This is why implementing proper pod-level security is essential, especially in multi-tenant clusters or environments running untrusted code.

Implementing Pod Security Standards

Step 1: Enable the Pod Security Admission Controller

For Kubernetes v1.25+, the Pod Security Admission Controller is enabled by default. For earlier versions, you’ll need to enable it in your API server configuration:

apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --admission-control=...,PodSecurity
    # Other API server flags

Step 2: Configure Security Standards for Namespaces

Apply labels to namespaces to specify which security standards should be enforced:

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

The three label types serve different purposes:

• enforce: Rejects non-compliant pods
• audit: Logs violations but allows pods to run
• warn: Sends warnings to users but allows pods to run

Step 3: Test Pod Security Enforcement

Let’s test our configuration by attempting to deploy a privileged pod to our secure namespace:

# Create the namespace with restricted security standards
kubectl create namespace secure-production
kubectl label namespace secure-production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

# Try to deploy a privileged pod
cat <<EOF | kubectl apply -f - -n secure-production
apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
spec:
  containers:
  - name: nginx
    image: nginx
    securityContext:
      privileged: true
EOF

This deployment will be rejected with an error message indicating which security constraints were violated.

Migrating from Pod Security Policies

For organizations transitioning from PSPs, here’s a general migration approach:

1. Audit current PSPs: Analyze your existing PSPs to understand your security requirements
2. Map PSPs to Standards: Determine which security profile (Privileged, Baseline, Restricted) is appropriate for each namespace
3. Configure enforcement: Apply labels to namespaces based on your mapping
4. Test in audit mode: Begin with audit to identify violations without disrupting workloads
5. Remediate non-compliant pods: Update workload definitions to comply with security standards
6. Enable enforcement: Switch to enforce once workloads are compliant

Best Practices for Pod Security

Beyond the standard profiles, consider these additional security measures:

• Use a dedicated security namespace: Create a separate namespace for security-critical components
• Implement exemptions carefully: Use pod-security.kubernetes.io/exempt: namespace for truly necessary exceptions
• Combine with Network Policies: Restrict pod-to-pod communication
• Use OPA/Gatekeeper: For more complex custom policies beyond Pod Security Standards
• Regularly audit: Continuously review security profiles and update as needed

Practical Example: Restricting Capabilities

The restricted profile limits what Linux capabilities containers can use. Here’s how to explicitly set allowed capabilities for a container:

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      capabilities:
        drop:
        - ALL
        add:
        - NET_BIND_SERVICE
      allowPrivilegeEscalation: false
      runAsNonRoot: true
      seccompProfile:
        type: RuntimeDefault

This configuration:

• Drops all capabilities by default
• Adds only the specific capability needed (NET_BIND_SERVICE)
• Prevents privilege escalation
• Ensures the container runs as a non-root user
• Uses the default seccomp profile

Conclusion

Pod Security Standards provide a straightforward, namespace-centric approach to securing your Kubernetes workloads. By selecting and implementing the appropriate security profiles for different namespaces, you can significantly reduce the attack surface of your containers while maintaining operational flexibility.

As Kubernetes security continues to evolve, staying informed about best practices and emerging threats remains crucial. The transition from PSPs to Pod Security Standards represents Kubernetes’ commitment to improving security while simplifying implementation.

Further Reading

• Kubernetes Pod Security Standards Documentation
• Enforcing Pod Security Standards with Namespace Labels
• Pod Security Admission Controller Stable Release Notes
• GKE Pod Security Standards Implementation
• Implementing Pod Security Standards in Amazon EKS