DEV Community

Cover image for Kubernetes Security Context: A Comprehensive Guide
Tandap Noel Bansikah
Tandap Noel Bansikah

Posted on

Kubernetes Security Context: A Comprehensive Guide

#kubernetes #security #cloudnative #devops

Table of Contents

  1. Introduction
  2. What is Security Context?
  3. Security Context Fields
  4. Pod-level vs Container-level Security Context
  5. Practical Examples
  6. Security Context Constraints
  7. Best Practices
  8. Troubleshooting
  9. References

Introduction

Security is a critical aspect of container orchestration, and Kubernetes provides robust mechanisms to enforce security policies at the pod and container level. One of the most important features for container security is the Security Context, which allows you to define privilege and access control settings for pods and containers.

This article provides a comprehensive overview of Kubernetes Security Context, covering both theoretical concepts and practical implementations based on official Kubernetes documentation.

What is Security Context?

A Security Context defines privilege and access control settings for a Pod or Container. It includes settings such as:

  • User ID (UID) and Group ID (GID) for running processes
  • Linux capabilities
  • SELinux options
  • AppArmor profiles
  • Seccomp profiles
  • File system permissions
  • Privilege escalation controls

Security contexts help enforce the principle of least privilege by ensuring containers run with only the minimum permissions necessary to function correctly.

Security Context Fields

Core Security Context Fields

Based on the official Kubernetes documentation, here are the key fields available in a Security Context:

User and Group Settings

  • runAsUser: Specifies the user ID to run the container processes
  • runAsGroup: Specifies the primary group ID for container processes
  • runAsNonRoot: Indicates that the container must run as a non-root user
  • fsGroup: Defines a file system group ID for volume ownership

Privilege Controls

  • privileged: Determines if the container runs in privileged mode
  • allowPrivilegeEscalation: Controls whether a process can gain more privileges
  • readOnlyRootFilesystem: Mounts the container's root filesystem as read-only

Linux Security Modules

  • seLinuxOptions: SELinux security context settings
  • appArmorProfile: AppArmor profile configuration
  • seccompProfile: Seccomp profile settings

Capabilities

  • capabilities: Linux capabilities to add or drop

Pod-level vs Container-level Security Context

Security Context can be specified at two levels:

Pod-level Security Context

Applied to all containers in the pod (unless overridden at container level):

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: sec-ctx-demo
    image: busybox:1.28
    command: [ "sh", "-c", "sleep 1h" ]
Enter fullscreen mode Exit fullscreen mode

Container-level Security Context

Applied to specific containers and overrides pod-level settings:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-2
spec:
  containers:
  - name: sec-ctx-demo
    image: busybox:1.28
    command: [ "sh", "-c", "sleep 1h" ]
    securityContext:
      runAsUser: 2000
      allowPrivilegeEscalation: false
Enter fullscreen mode Exit fullscreen mode

Practical Examples

Let's explore various Security Context configurations with practical examples.

Example 1: Basic User and Group Configuration 

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-1
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: sec-ctx-vol
    image: busybox:1.28
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
Enter fullscreen mode Exit fullscreen mode

What this does:

  • Runs the container process as user ID 1000
  • Sets the primary group ID to 3000
  • Sets the file system group to 2000 (volumes will be owned by this group)

Example 2: Non-Root User Enforcement 

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-2
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: sec-ctx-demo
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
Enter fullscreen mode Exit fullscreen mode

What this does:

  • Ensures the container cannot run as root
  • Prevents privilege escalation
  • Mounts the root filesystem as read-only

Example 3: Capabilities Management 

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-3
spec:
  containers:
  - name: sec-ctx-demo
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]
        drop: ["ALL"]
Enter fullscreen mode Exit fullscreen mode

What this does:

  • Drops all default capabilities
  • Adds only NET_ADMIN and SYS_TIME capabilities

Example 4: SELinux Configuration 

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4
spec:
  securityContext:
    seLinuxOptions:
      level: "s0:c123,c456"
  containers:
  - name: sec-ctx-demo
    image: gcr.io/google-samples/node-hello:1.0
Enter fullscreen mode Exit fullscreen mode

Example 5: Seccomp Profile 

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-5
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: sec-ctx-demo
    image: gcr.io/google-samples/node-hello:1.0
Enter fullscreen mode Exit fullscreen mode

Example 6: Complete Security Hardening 

apiVersion: v1
kind: Pod
metadata:
  name: hardened-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    runAsGroup: 10001
    fsGroup: 10001
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: hardened-container
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL
    resources:
      limits:
        memory: "128Mi"
        cpu: "100m"
      requests:
        memory: "64Mi"
        cpu: "50m"
    volumeMounts:
    - name: tmp-volume
      mountPath: /tmp
  volumes:
  - name: tmp-volume
    emptyDir: {}
Enter fullscreen mode Exit fullscreen mode

Security Context Constraints

Pod Security Standards

Kubernetes provides Pod Security Standards that work with Security Context:

  1. Privileged: Unrestricted policy
  2. Baseline: Minimally restrictive policy
  3. Restricted: Heavily restricted policy

Example Pod Security Policy (Deprecated in favor of Pod Security Standards) 

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
    - 'persistentVolumeClaim'
  runAsUser:
    rule: 'MustRunAsNonRoot'
  seLinux:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'RunAsAny'
Enter fullscreen mode Exit fullscreen mode

Best Practices

1. Always Run as Non-Root 

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
Enter fullscreen mode Exit fullscreen mode

2. Drop All Capabilities by Default 

securityContext:
  capabilities:
    drop:
    - ALL
Enter fullscreen mode Exit fullscreen mode

3. Use Read-Only Root Filesystem 

securityContext:
  readOnlyRootFilesystem: true
Enter fullscreen mode Exit fullscreen mode

4. Disable Privilege Escalation 

securityContext:
  allowPrivilegeEscalation: false
Enter fullscreen mode Exit fullscreen mode

5. Use Seccomp Profiles 

securityContext:
  seccompProfile:
    type: RuntimeDefault
Enter fullscreen mode Exit fullscreen mode

6. Set Resource Limits 

resources:
  limits:
    memory: "128Mi"
    cpu: "100m"
  requests:
    memory: "64Mi"
    cpu: "50m"
Enter fullscreen mode Exit fullscreen mode

Troubleshooting

Common Issues and Solutions

1. Permission Denied Errors

Problem: Container fails to start due to permission issues
Solution: Check runAsUser, runAsGroup, and fsGroup settings

kubectl logs <pod-name>
kubectl describe pod <pod-name>
Enter fullscreen mode Exit fullscreen mode

2. Capability Issues

Problem: Application requires specific capabilities
Solution: Add required capabilities while dropping unnecessary ones

securityContext:
  capabilities:
    add: ["NET_BIND_SERVICE"]
    drop: ["ALL"]
Enter fullscreen mode Exit fullscreen mode

3. File System Access Issues

Problem: Cannot write to mounted volumes
Solution: Set appropriate fsGroup

securityContext:
  fsGroup: 2000
Enter fullscreen mode Exit fullscreen mode

Debugging Commands 

# Check pod security context
kubectl get pod <pod-name> -o yaml | grep -A 10 securityContext

# Exec into pod to check user/group
kubectl exec -it <pod-name> -- id

# Check file permissions
kubectl exec -it <pod-name> -- ls -la /path/to/volume
Enter fullscreen mode Exit fullscreen mode

Testing Security Context

Create a Test Pod 

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: security-test
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: test-container
    image: busybox:1.28
    command: ["sleep", "3600"]
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL
EOF
Enter fullscreen mode Exit fullscreen mode

Verify Security Settings 

# Check user and group
kubectl exec security-test -- id

#output
uid=1000 gid=3000 groups=2000,3000

# Try to escalate privileges (should fail)
kubectl exec security-test -- su -

#output
su: must be suid to work properly
command terminated with exit code 1

# Check capabilities
kubectl exec security-test -- cat /proc/1/status | grep Cap

#output
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000000000000000
CapAmb: 0000000000000000
Enter fullscreen mode Exit fullscreen mode

Conclusion

Security Context is a fundamental component of Kubernetes security that provides granular control over how pods and containers run in your cluster. By properly configuring Security Context, you can enhance your cluster's security posture and follow the principle of least privilege.

Key takeaways: start with restrictive settings, test thoroughly, and combine Security Context with other Kubernetes security measures for comprehensive protection. Security is an ongoing process - regularly review and update your configurations as your applications and threat landscape evolve.

This article is based on Kubernetes official documentation and best practices for container security. Always refer to the latest Kubernetes documentation for the most up-to-date information.

References

Top comments (0)