Lesson 07 — Root vs Non-Root Containers

Learning Objectives

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

Understand the difference between root and non-root containers
Learn why running as root is a security risk
Understand how attackers exploit root containers
Configure Kubernetes workloads to run as non-root
Implement non-root execution using Security Contexts
Apply enterprise workload security practices in Amazon EKS
Follow least privilege principles for containerized applications

Why This Matters

Every process running inside a Linux container executes under a user account.

That user determines:

Which files can be accessed
Which processes can be managed
Which system resources are available
What privileges the application has

If an application runs as the root user, it gains elevated privileges inside the container.

If that application is compromised, attackers inherit those privileges, making privilege escalation and container escape significantly easier.

Running workloads as non-root users is one of the simplest and most effective ways to reduce Kubernetes security risks.

Understanding Linux Users

Linux identifies users using a User ID (UID).

The most important user is:

UID: 0

↓

Root User

↓

Full Administrative Privileges

All other users have limited permissions.

Example:

UID: 1000

↓

Application User

↓

Restricted Access

Root Container

A root container runs its primary application using UID 0.

Application

↓

UID 0

↓

Root User

↓

Elevated Privileges

The application can perform privileged operations that ordinary users cannot.

Non-Root Container

A non-root container runs using a dedicated application user.

Application

↓

UID 1000

↓

Application User

↓

Limited Permissions

This significantly limits the impact of a compromise.

Root vs Non-Root Comparison

Root Container	Non-Root Container
Runs as UID 0	Runs as non-zero UID
Elevated privileges	Limited permissions
Higher attack surface	Reduced attack surface
Easier privilege escalation	Harder privilege escalation
Greater container escape risk	Improved isolation
Not recommended for production	Recommended for production

Why Running as Root is Dangerous

A root process may be able to:

Modify application files
Change file ownership
Install software
Access sensitive directories
Modify permissions
Interact with host resources
Abuse Linux capabilities

If the container is compromised, attackers inherit all available root privileges.

Example Attack

Application Vulnerability

↓

Remote Code Execution

↓

Shell Access

↓

Application Running as Root

↓

Full Root Privileges

The attacker now controls the container with administrative permissions.

Running as Non-Root

With non-root execution:

Application Vulnerability

↓

Remote Code Execution

↓

Shell Access

↓

Application User

↓

Limited Permissions

The attacker encounters additional restrictions, reducing the impact of the compromise.

Security Context Configuration

Kubernetes uses the Security Context to enforce non-root execution.

Example:

securityContext:
  runAsNonRoot: true

This prevents the container from starting if it attempts to run as the root user.

Specifying the User ID

Administrators can define the exact Linux user.

Example:

securityContext:
  runAsUser: 1000

This ensures the application always runs using the specified non-root account.

Group Configuration

Applications can also execute using a dedicated group.

Example:

securityContext:
  runAsGroup: 1000

This provides consistent file ownership and access control across workloads.

File Permissions

Container

↓

Application User

↓

Files

↓

Read

↓

Write (Authorised Only)

Applications can only access files they are permitted to use.

Combining Security Controls

Enterprise workloads commonly combine multiple controls.

Non-Root User

+

Read-Only Root Filesystem

+

Dropped Linux Capabilities

+

Seccomp

+

Pod Security Standards

↓

Secure Workload

No single control is sufficient on its own.

Layered security provides stronger protection.

Root Containers and Container Escape

Root execution increases the likelihood of container escape.

Compromised Root Container

↓

Host Interaction

↓

Kernel Exploitation

↓

Node Compromise

Although root inside a container is not automatically root on the host, it provides attackers with more opportunities to exploit vulnerabilities.

Amazon EKS Architecture

Developer

↓

Git Repository

↓

CI/CD Pipeline

↓

Amazon EKS

↓

Pod Security Admission

↓

Security Context

↓

runAsNonRoot

↓

Worker Node

↓

Application

Every deployment can enforce non-root execution automatically.

Enterprise Example

A healthcare provider operates hundreds of patient-facing applications on Amazon EKS.

Its workload security policy requires:

runAsNonRoot: true
runAsUser: 1000
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
Dropped Linux Capabilities
RuntimeDefault Seccomp
Restricted Pod Security Standards

If a developer accidentally deploys a container that runs as root, Pod Security Admission blocks the deployment before it reaches production.

This ensures every workload follows a consistent security baseline.

Common Risks

Cloud Security Engineers frequently discover:

Containers running as UID 0
Missing runAsNonRoot
Undefined runAsUser
Images that require root unnecessarily
Excessive Linux capabilities
Writable root filesystems
Privileged containers
Missing admission policies
Legacy applications designed for root execution
Weak CI/CD validation

These weaknesses increase the likelihood of privilege escalation and container compromise.

Enterprise Monitoring

Security teams should monitor:

Containers running as UID 0
Failed non-root policy validations
Pod Security Admission denials
Security Context changes
Runtime privilege escalation attempts
Kubernetes audit logs
CI/CD security scan results
Container runtime events
Image compliance reports
Workload policy violations

Continuous monitoring ensures workloads remain compliant after deployment.

Enterprise Implementation Strategy

A recommended rollout:

Step 1

↓

Inventory Container Images

↓

Step 2

↓

Identify Root Containers

↓

Step 3

↓

Update Container Images

↓

Step 4

↓

Configure runAsUser

↓

Step 5

↓

Enable runAsNonRoot

↓

Step 6

↓

Validate in CI/CD

↓

Step 7

↓

Deploy to Production

↓

Step 8

↓

Continuously Monitor

This phased approach minimizes application compatibility issues while improving workload security.

Best Practices

As a Kubernetes Security Engineer:

Always run production containers as non-root users.
Enable runAsNonRoot: true for production workloads.
Specify explicit runAsUser and runAsGroup values.
Avoid container images that require root privileges.
Combine non-root execution with Read-Only Root Filesystems.
Drop unnecessary Linux Capabilities.
Disable privilege escalation.
Use Pod Security Admission to enforce non-root execution.
Validate Security Contexts in CI/CD pipelines.
Regularly audit workloads for root execution.

Running containers as non-root is a foundational workload security control and should be the default for enterprise Kubernetes deployments.

Real-World Scenario

An e-commerce company hosts its online shopping platform on Amazon EKS.

During development, a new container image is built using the default root user.

When the deployment reaches the CI/CD pipeline:

Image scanning identifies root execution.
Pod Security Admission validates the workload.
The deployment violates the organization’s Restricted policy.
The deployment is rejected.

Developers update the Dockerfile to create a dedicated application user and configure:

runAsUser: 1000
runAsNonRoot: true

The application is redeployed successfully and now operates with significantly fewer privileges.

This simple change greatly reduces the risk of privilege escalation if the application is ever compromised.

Key Takeaways

After completing this lesson, you should understand:

The difference between root and non-root containers
Why root execution increases security risks
How Kubernetes enforces non-root execution
How Security Contexts configure user identities
The role of runAsNonRoot and runAsUser
Enterprise implementation strategies
Monitoring and workload governance best practices

Running containers as non-root is one of the most effective and widely recommended Kubernetes security practices. When combined with Security Contexts, Pod Security Standards, Read-Only Root Filesystems, Linux Capabilities and admission policies, it forms a strong foundation for securing workloads in Amazon EKS.

Knowledge Check

Question 1

What is the Linux User ID (UID) of the root user?

A. 1000
B. 500
C. 0
D. 1

Answer: C

Question 2

Which Kubernetes Security Context setting prevents a container from running as the root user?

A. privileged: false
B. readOnlyRootFilesystem: true
C. runAsNonRoot: true
D. hostNetwork: false

Answer: C

Question 3

Why is running containers as non-root recommended?

A. It increases CPU performance.
B. It reduces the impact of a container compromise by limiting privileges.
C. It automatically encrypts container traffic.
D. It increases storage capacity.

Answer: B

Question 4

Which Security Context setting specifies the Linux User ID that a container should run as?

A. runAsGroup
B. runAsUser
C. allowPrivilegeEscalation
D. capabilities

Answer: B

Question 5

Which combination represents enterprise best practice?

A. Run all production containers as root with privileged mode enabled.
B. Run containers as non-root users, disable privilege escalation, use Read-Only Root Filesystems and enforce Pod Security Standards.
C. Enable host networking for all workloads.
D. Grant all Linux Capabilities by default.

Answer: B

What’s Next?

In the next lesson, you will learn about Resource Limits, exploring how Kubernetes uses CPU and memory requests and limits to prevent resource exhaustion, improve workload stability and protect Amazon EKS clusters from denial-of-service (DoS) attacks caused by runaway containers.

➡️ Next Lesson: Lesson 08 — Resource Limits