Skip to content

6.16 Kubernetes Security Contexts

Abstract

Security Contexts define privilege and access control settings for Pods and Containers. They allow you to configure user IDs, permissions, and Linux capabilities to enforce the principle of least privilege in Kubernetes workloads.

Why Security Contexts Matter

Containers share the host kernel, so improper configuration can allow workloads to gain excessive privileges.

Security contexts allow you to:

  • Run containers as non-root users
  • Restrict Linux capabilities
  • Prevent privilege escalation
  • Improve cluster security posture

Warning

Running containers with default settings may allow processes to run as root, which increases security risk in production environments.

Security Context Scope

Security contexts can be defined at two levels.

Level Applies To
Pod Level All containers in the pod
Container Level Only a specific container

If both are defined:

  • Container settings override Pod settings

Pod Level Security Context

Pod-level security settings apply to all containers inside the pod.

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
spec:
  securityContext:
    runAsUser: 1000
  containers:
    - name: ubuntu
      image: ubuntu
      command: ["sleep","3600"]

Note

All containers in the pod will run with UID 1000 unless overridden at the container level.

Container Level Security Context

You can apply security settings directly to a container.

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
spec:
  containers:
  - name: ubuntu
    image: ubuntu
    command: ["sleep","3600"]
    securityContext:
      runAsUser: 1000

Tip

Container-level configuration provides fine-grained control over privileges.

Linux Capabilities in Kubernetes

Linux capabilities split root privileges into smaller permissions.

Examples:

  • NET_ADMIN
  • SYS_ADMIN
  • MAC_ADMIN
  • KILL
  • CHOWN

Kubernetes allows you to add or drop capabilities using security contexts.

Adding Linux Capabilities

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
spec:
  containers:
  - name: ubuntu
    image: ubuntu
    command: ["sleep","3600"]
    securityContext:
      capabilities:
        add: ["MAC_ADMIN"]

Note

Capabilities can only be configured at the container level, not at the pod level.

Removing Capabilities

securityContext:
  capabilities:
    drop:
      - NET_RAW

Success

Dropping unnecessary capabilities greatly reduces attack surface.

Production Best Practices

Recommended Production Practices

  • Always run containers as non-root users
  • Drop unnecessary Linux capabilities
  • Avoid privileged containers
  • Enforce read-only root filesystems
  • Prevent privilege escalation
  • Use Pod Security Standards

Example hardened container:

securityContext:
  runAsUser: 1000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop:
      - ALL

Do's and Don'ts

Do

  • Run containers with non-root UID
  • Drop unused Linux capabilities
  • Restrict privilege escalation
  • Use minimal container permissions
  • Use Pod Security Admission policies

Don't

  • Don't run containers as root
  • Don't add unnecessary capabilities
  • Don't use privileged containers
  • Don't allow unrestricted filesystem access

Danger

Privileged containers effectively have root access to the host, which can compromise the entire node.

Security Context Example (Hardened Pod)

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
  - name: app
    image: nginx
    securityContext:
      runAsUser: 1000
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL

Summary

Quote

  • Security contexts control container privileges
  • They can be applied at pod or container level
  • Container settings override pod settings
  • Linux capabilities allow fine-grained permission control
  • Production workloads should enforce least privilege