Skip to content

Pod Security

Kubernetes pods are the smallest deployable units, but their security configuration is critical to preventing vulnerabilities and ensuring system integrity. Misconfigured pods can expose the cluster to privilege escalation, data leaks, and unauthorized access. This section covers how to secure pods using security contexts, prevent privilege escalation, and follow best practices for robust pod configurations.

Pod Security Context

The securityContext field in a pod's spec defines how the container processes run, including user permissions, capabilities, and privilege settings. Key parameters include:

  • runAsUser: Specifies the user ID (UID) the container runs as. Avoid using root (UID 0) unless absolutely necessary.
  • runAsGroup: Defines the group ID (GID) for the container.
  • capabilities: Grants or restricts Linux capabilities (e.g., CAP_NET_BIND_SERVICE for binding to privileged ports).
  • privileged: When true, the container has full access to the host’s devices. Set this to false by default.
  • allowPrivilegeEscalation: Prevents processes from escalating privileges (e.g., via sudo). Set to false to block this.

Example: Non-root user with limited capabilities 

spec:
  containers:
  - name: secure-app
    image: your-image
    securityContext:
      runAsUser: 1000
      runAsGroup: 3000
      capabilities:
        drop:
        - ALL
      allowPrivilegeEscalation: false

Privilege Escalation Prevention

Privilege escalation occurs when a process gains higher permissions than intended, often via exploiting misconfigurations. To mitigate this:

  1. Avoid running as root: Use non-root users (e.g., runAsUser: 1000) and runAsNonRoot: true to enforce this.
  2. Disable privileged mode: Set privileged: false unless explicitly required for specific workloads.
  3. Restrict capabilities: Drop unnecessary capabilities using the capabilities.drop field.
  4. Use PodSecurity Admission Controller: Enforce security policies via Kubernetes' built-in admission controllers (e.g., PodSecurity), which validate pod specs against predefined policies like Restricted or Privileged.

Example: Enforce non-root execution 

spec:
  containers:
  - name: secure-app
    image: your-image
    securityContext:
      runAsNonRoot: true
      runAsUser: 1000

Best Practices for Secure Pod Configuration

  • Run as non-root users: Always set runAsUser to a non-root UID and enable runAsNonRoot.
  • Limit capabilities: Drop unused capabilities to minimize attack surfaces.
  • Disable privileged mode: Avoid privileged: true unless absolutely necessary.
  • Use read-only file systems: Set readOnlyRootFilesystem: true to prevent container escape attacks.
  • Secure secrets: Use Kubernetes Secrets or Vault instead of hardcoding credentials in images.
  • Leverage admission controllers: Enable PodSecurity to enforce security policies across the cluster.

Example: Full security context configuration 

spec:
  containers:
  - name: secure-app
    image: your-image
    securityContext:
      runAsUser: 1000
      runAsGroup: 3000
      capabilities:
        drop:
        - ALL
      readOnlyRootFilesystem: true
      allowPrivilegeEscalation: false

Key takeaways

  • Always run containers as non-root users to reduce exploitation risks.
  • Disable privileged mode and restrict capabilities to minimize attack surfaces.
  • Use securityContext to enforce user, group, and capability settings.
  • Leverage Kubernetes admission controllers to enforce security policies.
  • Keep file systems read-only and avoid hardcoding sensitive data in pod specs.