Security Context in Kubernetes

 security context:

In Kubernetes, a security context defines privileges for individual pods or containers. You can use security context to grant containers or pods permissions such as the right to access an external file or run in privileged mode.

User Permission for Pod-Level Security Context.

The securityContext at the Pod level applies to all containers within the Pod.

for pods level

Scenario 1: Enforcing a Non-Root User for Security

# cat security-context-pods-demo.yaml

apiVersion: v1

kind: Pod

metadata:

  name: security-context-demo

spec:

  securityContext:

    runAsUser: 1000

    runAsGroup: 3000

    fsGroup: 2000

  volumes:

  - name: demo-vol

    emptyDir: {}

  containers:

  - name: sc-demo

    image: busybox:1.28

    command: [ "sh", "-c", "sleep 1h" ]

    volumeMounts:

    - name: demo-vol

      mountPath: /data/demo

Parameter	Description
runAsUser	Runs all containers as a specific user (UID)
runAsGroup	Sets the primary group (GID) for all containers
fsGroup	Assigns a group ID for file system access in volumes
fsGroupChangePolicy	Controls how fsGroup is applied to volumes (OnRootMismatch or Always)
seccompProfile	Defines the Seccomp profile (RuntimeDefault, Unconfined, or a custom profile)
sysctls	Configures kernel parameters (e.g., net.ipv4.ip_forward=1)

# kubectl apply -f security-context-pods-demo.yaml

# kubectl get pods

# kubectl exec -it security-context-demo -- /bin/sh

verify the applied security settings using:

# kubectl get pod security-context-demo -o yaml | grep -A10 securityContext

# cd /data/demo

# echo hello devopspro >> myfile

# ls -l

When both Pod-level and Container-level runAsUser are set in Kubernetes, Container-level runAsUser is preferred.

Pod level will not be used, container level runAsUser :2000 will be used.

Pod level will not be used, container level runAsUser :2000 will be used.

Scenario 2: Enforcing Read-Only Filesystem

Scenario 3: Applying Seccomp for Syscall Restriction

Scenario 4: Kernel Parameter Customization (sysctls)

Scenario 5: Restricting Container Privileges.

User Permission in Container-Level Security Context

Each container can have its own securityContext, which overrides Pod-level settings.

Scenario 1: Running Containers as a Non-Root User

Use Case: Prevent security risks by ensuring containers do not run as root.

 

apiVersion: v1

kind: Pod

metadata:

  name: non-root-container

spec:

  containers:

  - name: app-container

    image: busybox

    command: ["sleep", "3600"]

    securityContext:

      runAsUser: 1000  # Run as non-root user

      runAsGroup: 3000  # Assign group ID

      allowPrivilegeEscalation: false  # Prevent privilege escalation

 

Scenario 2: Enforcing Read-Only Root Filesystem

apiVersion: v1

kind: Pod

metadata:

  name: read-only-container

spec:

  containers:

  - name: secure-app

    image: busybox

    command: ["sleep", "3600"]

    securityContext:

      readOnlyRootFilesystem: true  # Make root filesystem read-only

 

# kubectl exec -it read-only-container -- sh

# touch /testfile

This confirms that the root filesystem is read-only, preventing unauthorized writes.

 touch: /testfile: Read-only file system

touch /tmp/testfile

 ls /tmp

 

Scenario 3: Dropping Unnecessary Linux Capabilities

Use Case: Reduce the risk of privilege escalation by dropping unwanted capabilities.

Drop all default Linux capabilities using drop: ["ALL"].

apiVersion: v1

kind: Pod

metadata:

  name: drop-capabilities

spec:

  containers:

  - name: secure-app

    image: busybox

    command: ["sleep", "3600"]

    securityContext:

      capabilities:

        drop: ["ALL"]  # Drop all capabilities

 

# kubectl exec -it drop-capabilities -- sh

# cat /proc/$$/status | grep CapEff

Since we dropped all capabilities, the output should be 0000000000000000, meaning no extra privileges are available.

 

We can create files and directories but cannot do any configuration.

 

Scenario 4: Adding Specific Linux Capabilities

Use Case: Grant specific privileges like network administration without running as root.

Commonly Used Linux Capabilities.

Capability	Description
NET_ADMIN	Modify network interfaces, routing, firewall rules (iptables)
NET_RAW	Allows sending raw packets (needed for ping)
SYS_TIME	Modify system clock
CHOWN	Change file ownership
KILL	Kill any process
SETUID	Change user ID
SETGID	Change group ID
SYS_ADMIN	Full system administration (DANGEROUS 🚨)

 

added NET_ADMIN, we can now try modifying network settings inside the container.

apiVersion: v1

kind: Pod

metadata:

  name: add-capabilities

spec:

  containers:

  - name: network-tool

    image: busybox

    command: ["sleep", "3600"]

    securityContext:

      capabilities:

        add: ["NET_ADMIN"]  # Allow modifying network settings

# kubectl exec -it add-capabilities – sh

# cat /proc/$$/status | grep CapEff

added NET_ADMIN, we can now try modifying network settings inside the container.

Scenario 5: Restricting Privilege Escalation

Scenario 6: Using Seccomp for Syscall Restriction

Scenario 7: Running a Privileged Container (⚠ Not Recommended)

apiVersion: v1

kind: Pod

metadata:

  name: privileged-container

spec:

  containers:

  - name: privileged-app

    image: busybox

    command: ["sleep", "3600"]

    securityContext:

      privileged: true  # Full access to host resources (⚠ Risky)

 

Differences: Pod-Level vs Container-Level

Feature	Pod-Level securityContext	Container-Level securityContext
Scope	Affects all containers in the Pod	Affects only the specific container
runAsUser / runAsGroup	Applies to all containers unless overridden	Applies only to the specific container
fsGroup	Affects all mounted volumes	N/A
Capabilities	Cannot be set at Pod level	Can be added or dropped per container
Privileged Mode	Cannot be set at Pod level	Can be enabled per container
readOnlyRootFilesystem	Cannot be set at Pod level	Can be enabled per container
AllowPrivilegeEscalation	Cannot be set at Pod level	Can be enabled per container
Sysctl Settings	Can set kernel parameters (e.g., network tuning)	N/A