Lesson 02 — Security Contexts

Learning Objectives

By the end of this lesson, you will be able to:

Understand what Security Contexts are
Learn how Security Contexts protect Kubernetes workloads
Configure secure Pod and container runtime settings
Understand user and group permissions
Prevent privilege escalation
Configure Linux security features
Implement Security Contexts in Amazon EKS
Apply enterprise workload security best practices

Why This Matters

Every container running inside Kubernetes executes with a set of permissions.

If those permissions are overly permissive, an attacker who compromises a container may be able to:

Escape the container
Modify the operating system
Access sensitive files
Escalate privileges
Attack other containers
Compromise Kubernetes nodes

Security Contexts allow Kubernetes administrators to control exactly how Pods and containers run, significantly reducing the attack surface.

What is a Security Context?

A Security Context defines security settings that control how a Pod or container executes.

These settings determine:

User identity
Group identity
Linux capabilities
Privilege escalation
Filesystem permissions
Seccomp profiles
SELinux labels (where supported)
Runtime behaviour

Security Contexts are one of the most important workload security controls in Kubernetes.

Where Can Security Contexts Be Applied?

Security Contexts can be configured at two levels.

Pod

↓

Pod Security Context

↓

Container Security Context

Pod Security Context applies default settings to all containers in the Pod.
Container Security Context overrides settings for individual containers.

Pod-Level Security Context

A Pod Security Context defines settings shared by every container.

Example:

Pod

├── Container A

├── Container B

└── Container C

↓

Shared Security Settings

This ensures consistent security across all containers.

Container-Level Security Context

Individual containers may require different permissions.

Example:

Pod

├── Web Server

↓

Restricted Settings

---------------------

Pod

├── Log Collector

↓

Additional Permissions

Container-specific Security Contexts provide fine-grained control where required.

Common Security Context Settings

A Security Context commonly controls:

runAsUser
runAsGroup
runAsNonRoot
fsGroup
allowPrivilegeEscalation
privileged
readOnlyRootFilesystem
capabilities
seccompProfile

Each setting strengthens workload security in a different way.

Running as Non-Root

By default, some container images run as the Linux root user.

Example:

UID 0

↓

Root User

↓

Full System Access

Running containers as root significantly increases the impact of a compromise.

Instead, production workloads should run as non-root users.

runAsNonRoot

The runAsNonRoot setting ensures that Kubernetes refuses to start a container if it attempts to run as root.

Example:

runAsNonRoot: true

Benefits:

Prevents accidental root execution
Reduces privilege escalation risks
Supports Pod Security Standards
Improves compliance

runAsUser

The runAsUser setting specifies the Linux User ID (UID) used by the container.

Example:

runAsUser: 1000

Instead of:

Root

↓

UID 0

The container runs as:

Application User

↓

UID 1000

Using dedicated application users improves isolation.

runAsGroup

The runAsGroup setting defines the Linux Group ID (GID).

Example:

runAsGroup: 1000

Files created by the application inherit the specified group ownership.

fsGroup

Applications often need shared access to mounted storage.

The fsGroup setting automatically assigns group ownership to mounted volumes.

Example:

fsGroup: 2000

This allows multiple containers within a Pod to access shared storage securely.

Preventing Privilege Escalation

Some applications attempt to gain additional Linux privileges during execution.

Security Contexts can prevent this.

Example:

allowPrivilegeEscalation: false

Result:

Application

↓

Requests Higher Privileges

↓

Denied

This greatly reduces the likelihood of privilege escalation attacks.

Privileged Containers

Privileged containers have almost unrestricted access to the host operating system.

Example:

Container

↓

Host Kernel

↓

Host Devices

↓

Operating System

Unless absolutely necessary, privileged containers should never be used for business applications.

readOnlyRootFilesystem

Most applications only need to read application files.

The root filesystem can therefore be mounted as read-only.

Example:

readOnlyRootFilesystem: true

Benefits include:

Prevents malware installation
Prevents runtime modifications
Improves application integrity
Reduces persistence opportunities for attackers

Linux Capabilities

Linux divides root privileges into smaller capabilities.

Examples include:

NET_ADMIN
SYS_ADMIN
CHOWN
SETUID
DAC_OVERRIDE

Rather than granting full root access, Kubernetes can selectively grant or remove capabilities.

The recommended approach is to drop all unnecessary capabilities.

Seccomp Profiles

Seccomp restricts which Linux system calls a container may execute.

Example:

seccompProfile:
  type: RuntimeDefault

Benefits include:

Reduced kernel attack surface
Protection against container escape techniques
Improved workload isolation

AppArmor and SELinux

Additional Linux security frameworks may also be used.

AppArmor

Restricts:

File access
Process capabilities
Network operations

SELinux

Provides:

Mandatory Access Control (MAC)
Fine-grained security labels
Strong workload isolation

Many enterprise Linux distributions support SELinux for Kubernetes nodes.

Security Context Evaluation

Developer

↓

Deploy Pod

↓

API Server

↓

Security Context Validation

↓

Pod Scheduled

↓

Container Starts

Security settings are evaluated before containers begin execution.

Enterprise Amazon EKS Architecture

Developer

↓

Git Repository

↓

CI/CD Pipeline

↓

Amazon EKS API Server

↓

Pod Security Admission

↓

Security Context Validation

↓

Worker Node

↓

Container Runtime

Security Contexts become part of every workload deployment.

Enterprise Example

A healthcare organisation operates patient management systems on Amazon EKS.

Every production workload must include:

runAsNonRoot: true
runAsUser: 1000
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
seccompProfile: RuntimeDefault
Drop unnecessary Linux capabilities

The CI/CD pipeline automatically validates these settings before deployment.

If any workload violates security requirements, deployment is rejected.

This ensures that every production application follows a consistent security baseline.

Common Security Context Risks

Cloud Security Engineers frequently identify:

Containers running as root
Privileged containers
Privilege escalation enabled
Missing Seccomp profiles
Writable root filesystems
Excessive Linux capabilities
Shared root users across applications
Missing user IDs
Weak filesystem permissions
Inconsistent Security Context configurations

These weaknesses increase the risk of container compromise and host-level attacks.

Enterprise Monitoring

Security teams should monitor:

Containers running as root
Privileged workloads
Security Context violations
Failed Pod admissions
Capability changes
Seccomp violations
Writable root filesystems
Container runtime events
Kubernetes audit logs
Admission Controller logs

Continuous monitoring helps ensure workloads remain compliant with security policies.

Enterprise Implementation Strategy

A recommended rollout approach:

Step 1

↓

Inventory Existing Workloads

↓

Step 2

↓

Identify High-Risk Containers

↓

Step 3

↓

Configure Security Contexts

↓

Step 4

↓

Test Applications

↓

Step 5

↓

Update CI/CD Validation

↓

Step 6

↓

Deploy to Production

↓

Step 7

↓

Continuously Monitor

Gradual adoption reduces operational risk while improving workload security.

Best Practices

As a Kubernetes Security Engineer:

Always run production containers as non-root users.
Set runAsNonRoot: true for all production workloads.
Define explicit runAsUser and runAsGroup values.
Disable privilege escalation unless absolutely required.
Avoid privileged containers.
Use read-only root filesystems whenever possible.
Drop unnecessary Linux capabilities.
Enable the RuntimeDefault Seccomp profile.
Validate Security Contexts in CI/CD pipelines.
Continuously audit workloads for compliance.

Security Contexts should be treated as mandatory controls rather than optional configuration.

Real-World Scenario

A software company deploys a new application to its Amazon EKS production cluster.

During deployment, a developer accidentally includes:

Root user execution
Privileged mode enabled
Writable root filesystem
Privilege escalation allowed

The organization’s admission policies validate every workload.

The deployment is evaluated against the required Security Context standards.

Because the workload violates multiple security controls:

The deployment is rejected.
The CI/CD pipeline reports the violations.
Developers correct the configuration.
A secure version of the application is successfully deployed.

The insecure workload never reaches production, preventing a potential container escape or privilege escalation attack.

Key Takeaways

After completing this lesson, you should understand:

What Security Contexts are
Pod-level and container-level Security Contexts
Running workloads as non-root users
Linux user and group permissions
Preventing privilege escalation
Read-only root filesystems
Linux capabilities
Seccomp, AppArmor and SELinux
Enterprise implementation strategies
Security Context best practices

Security Contexts are one of the most effective mechanisms for securing Kubernetes workloads. By enforcing least privilege, restricting runtime behaviour and integrating security validation into deployment pipelines, organizations can significantly reduce the attack surface of Amazon EKS environments.

Knowledge Check

Question 1

What is the primary purpose of a Kubernetes Security Context?

A. Configure networking
B. Define runtime security settings for Pods and containers
C. Manage persistent storage
D. Schedule workloads across nodes

Answer: B

Question 2

Which Security Context setting prevents containers from running as the root user?

A. privileged
B. runAsNonRoot
C. fsGroup
D. capabilities

Answer: B

Question 3

Which Security Context setting prevents a container from gaining additional Linux privileges during execution?

A. runAsGroup
B. allowPrivilegeEscalation: false
C. readOnlyRootFilesystem
D. fsGroup

Answer: B

Question 4

What is the purpose of the RuntimeDefault Seccomp profile?

A. Encrypt container traffic
B. Restrict Linux system calls available to containers
C. Configure DNS policies
D. Allocate additional CPU resources

Answer: B

Question 5

Which combination represents enterprise Security Context best practices?

A. Run containers as root with privileged mode enabled.
B. Use runAsNonRoot, disable privilege escalation, enable read-only root filesystems and drop unnecessary Linux capabilities.
C. Enable host networking for all workloads.
D. Allow unrestricted Linux capabilities for application compatibility.

Answer: B

What’s Next?

In the next lesson, you will learn about Pod Security Admission (PSA), exploring how Kubernetes enforces Pod Security Standards through admission control, Namespace labels, enforcement modes, and enterprise policy management to prevent insecure workloads from being deployed into Amazon EKS clusters.

➡️ Next Lesson: Lesson 03 — Pod Security Admission