Adhering to Restricted Pod Security Standards

With Kyverno the Restricted Pod Security Standards are enforced. This guide describes how to prep your application so that it adheres to this security standard.

1. Understand Restricted Pod Security Standards

Restricted Pod Security Standards are the most secure profile in Kubernetes, designed to enforce best practices for pod security. Key requirements include:

• No privileged pods
• No root user
• No privilege escalation
• No host process/namespace access
• No hostPort/network access
• No adding capabilities
• No running as root group
• SeccompProfile must be set

These restricted policies build on and extend the Baseline Pod Security Standards, adding stricter security requirements. Kyverno enforces these standards via policies, blocking non-compliant deployments.

note

Another important security measure is configuring Read-only root filesystem for pods. While this is not a strict requirement of the Restricted Pod Security Standard in Kubernetes, it is a best practice and is often recommended for enhanced security, especially in environments where immutability and least privilege are prioritized. In case you want to enforce this, you can add the following policy as a custom policy.

2. Prepare Your Application

A. Run as Non-Root User

• Set runAsNonRoot: true in your pod/container security context.
• Specify a non-root user (runAsUser: 1000) if your app requires a specific UID.
• Ensure your container image supports running as a non-root user. If not, rebuild the image with a non-root user or use securityContext.fsGroup to manage file permissions.

Example:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  fsGroup: 2000

B. Avoid Privileged Mode

• Never set privileged: true in your pod or container spec.
• Remove CAP_SYS_ADMIN or other unnecessary capabilities.

C. Prevent Privilege Escalation

• Set allowPrivilegeEscalation: false in the container security context.

Example:

securityContext:
  allowPrivilegeEscalation: false

D. Use Read-Only Root Filesystem

• Set readOnlyRootFilesystem: true if your app doesn’t need to write to the root filesystem.
• Use emptyDir or volumes for writable files.

Example:

securityContext:
  readOnlyRootFilesystem: true

E. Drop All Capabilities

• Drop all capabilities and only add back what’s necessary (e.g., NET_BIND_SERVICE).

Example:

securityContext:
  capabilities:
    drop: ["ALL"]
    add: ["NET_BIND_SERVICE"]

F. Avoid Host Process/Namespace Access

• Do not use hostPID, hostIPC, or hostNetwork unless absolutely required.
• Avoid hostPort unless necessary for networking.

3. Update Your Helm Chart or Manifests

• Review all deployments, statefulsets, and daemonsets for compliance.
• Use pod security context at both pod and container levels.

Example Pod Spec:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: my-container
    image: my-app:latest
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]
        add: ["NET_BIND_SERVICE"]

4. Deploy and Monitor

• Deploy your app and check for Kyverno policy violations in the cluster events:

  kubectl events

• Monitor Kyverno policy reports for violations:

  kubectl get policyreport -A

5. Common Pitfalls and Fixes

Issue	Solution
App fails to start as non-root	Rebuild the image with a non-root user or adjust file permissions.
App needs to write to root filesystem	Use volumes or emptyDir for writable paths.
App requires specific capabilities	Explicitly add only the required capabilities.
Legacy app requires root	Use a security context to run as non-root and adjust the app or use a wrapper script.

6. Handling Exceptions

While enforcing Restricted Pod Security Standards is critical for security, some workloads may genuinely require exceptions (e.g., legacy applications, monitoring agents, or specific system tools). Kyverno allows you to explicitly define exceptions for these cases, ensuring you remain in control of your cluster’s security posture.

info

Why Exceptions Are Acceptable

• Intentional exceptions demonstrate awareness and ownership of security risks.
• Granular control lets you relax policies only where necessary, rather than disabling them entirely.
• Auditability ensures exceptions are documented and reviewable.

For guidance on adding exceptions to Kyverno Policies, check out this tutorial.