Lesson 05 — Read-Only Root Filesystem

Learning Objectives

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

Understand what a Read-Only Root Filesystem is
Learn why immutable containers improve security
Understand how attackers abuse writable filesystems
Configure Read-Only Root Filesystems using Security Contexts
Learn enterprise implementation strategies
Secure applications running on Amazon EKS
Apply workload hardening best practices

Why This Matters

Containers are designed to be immutable.

Once a container image is built and deployed, its application code should not change.

However, if the container’s root filesystem remains writable, an attacker who compromises the application may:

Install malware
Download hacking tools
Modify application binaries
Change configuration files
Hide malicious software
Create persistence mechanisms

A Read-Only Root Filesystem prevents these activities by making the container’s filesystem immutable during runtime.

What is a Read-Only Root Filesystem?

A Read-Only Root Filesystem prevents containers from modifying files stored in the container image.

Instead of:

Application

↓

Read

↓

Write

↓

Modify Files

The container is limited to:

Application

↓

Read Files

↓

Execute Files

↓

No Modifications Allowed

The application can still run normally, but it cannot alter its own operating environment.

Writable vs Read-Only Filesystem

Writable Root Filesystem

Container

↓

Application

↓

Modify Files

↓

Install Software

↓

Create Scripts

An attacker can make persistent changes.

Read-Only Root Filesystem

Container

↓

Application

↓

Read Existing Files

↓

Write Blocked

Runtime modifications are denied.

Why Containers Should Be Immutable

Modern container security follows the concept of Immutable Infrastructure.

Instead of modifying running containers:

Fix Application

↓

Build New Image

↓

Deploy New Container

↓

Delete Old Container

Applications are updated by replacing containers—not modifying them.

This makes environments more predictable, secure and reproducible.

Common Attacker Activities

When a writable filesystem exists, attackers commonly:

Download malware
Install cryptocurrency miners
Create backdoors
Modify startup scripts
Replace application binaries
Add SSH keys
Install packet sniffers
Hide malicious tools

These actions become much more difficult with a Read-Only Root Filesystem.

Example Attack

Without filesystem protection:

Compromised Application

↓

Download Malware

↓

Install Malware

↓

Modify Startup Files

↓

Persistent Access

The compromise survives until the container is rebuilt or removed.

Read-Only Protection

With a Read-Only Root Filesystem:

Compromised Application

↓

Attempt File Modification

↓

Permission Denied

↓

Attack Blocked

The attacker cannot permanently modify the container image.

Configuring Read-Only Root Filesystems

Kubernetes enables this through the Security Context.

Example:

securityContext:
  readOnlyRootFilesystem: true

This instructs the container runtime to mount the root filesystem as read-only.

Where Applications Can Still Write

Some applications require temporary writable storage.

Instead of writing to the root filesystem, use:

EmptyDir volumes
Persistent Volumes
Temporary directories
External object storage
Databases

Example:

Application

↓

Temporary Volume

↓

Writable Storage

The application remains functional while the root filesystem stays protected.

Read-Only Root Filesystem with Volumes

Container

├── Root Filesystem

│      Read-Only

│

└── EmptyDir Volume

       Writable

Only the mounted volume allows writes.

This follows the principle of least privilege.

Read-Only Root Filesystem in Amazon EKS

Deployment workflow:

Developer

↓

Git Repository

↓

CI/CD Pipeline

↓

Amazon EKS

↓

Security Context

↓

Container Runtime

↓

Read-Only Filesystem Enabled

Every deployment can automatically enforce immutable containers.

Benefits of Read-Only Root Filesystems

Organizations gain several advantages:

Prevent malware persistence
Reduce attack surface
Protect application binaries
Improve workload integrity
Support compliance requirements
Encourage immutable infrastructure
Simplify incident recovery

Even if a container is compromised, attackers have far fewer options.

Enterprise Example

A global retail company deploys more than 3,500 containers on Amazon EKS.

Its production policy requires:

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

Applications requiring writable storage use dedicated volumes instead of modifying the container image.

This approach significantly reduces the impact of container compromise.

Applications That Require Writable Storage

Some applications legitimately need writable locations.

Examples include:

Log files
Cache directories
Temporary uploads
Runtime sockets
Session files

Rather than disabling Read-Only Root Filesystems, these directories should be mounted as writable volumes.

Example:

Container

↓

Writable Volume

↓

/tmp

↓

Application Cache

This preserves both functionality and security.

Common Risks

Cloud Security Engineers frequently discover:

Writable root filesystems
Applications storing data inside containers
Malware persistence
Modified application binaries
Unprotected runtime directories
Missing Security Contexts
Containers downloading software during execution
Poor immutable infrastructure practices
Manual production changes
Containers used as long-lived servers

These issues increase operational and security risks.

Enterprise Monitoring

Security teams should monitor:

Containers without Read-Only Root Filesystems
Security Context violations
File modification attempts
Admission Controller denials
Runtime security alerts
Container drift
Unauthorized package installation
Kubernetes audit logs
CI/CD validation failures
Workload policy violations

Continuous monitoring ensures workloads remain immutable after deployment.

Enterprise Implementation Strategy

A recommended rollout:

Step 1

↓

Inventory Applications

↓

Step 2

↓

Identify Writable Directories

↓

Step 3

↓

Move Writes to Volumes

↓

Step 4

↓

Enable Read-Only Root Filesystem

↓

Step 5

↓

Validate in CI/CD

↓

Step 6

↓

Deploy to Production

↓

Step 7

↓

Continuously Monitor

This gradual approach minimizes compatibility issues while improving security.

Read-Only Root Filesystem and Immutable Infrastructure

These concepts work together.

Source Code

↓

Build Container Image

↓

Scan Image

↓

Deploy Container

↓

Read-Only Runtime

↓

Replace Instead of Modify

Production containers should never be modified after deployment.

If changes are required:

Update source code
Build a new image
Redeploy the application

Never modify running production containers manually.

Best Practices

As a Kubernetes Security Engineer:

Enable readOnlyRootFilesystem: true for production workloads.
Store logs, cache files and temporary data in mounted volumes.
Follow immutable infrastructure principles.
Avoid modifying running containers.
Combine Read-Only Root Filesystems with non-root execution.
Disable privilege escalation.
Drop unnecessary Linux Capabilities.
Validate Security Contexts through CI/CD pipelines.
Monitor workloads for runtime drift.
Regularly review workloads for writable filesystem requirements.

A Read-Only Root Filesystem is a simple but highly effective control that significantly reduces post-compromise risk.

Real-World Scenario

A software company hosts its customer portal on Amazon EKS.

An attacker exploits a vulnerable web application and gains shell access inside the container.

The attacker attempts to:

Install malware
Replace application binaries
Download additional hacking tools
Create startup scripts for persistence

However, the container is configured with:

readOnlyRootFilesystem: true
Non-root execution
Disabled privilege escalation
Restricted Linux Capabilities
RuntimeDefault Seccomp

Every attempt to modify the filesystem fails because the root filesystem is mounted as read-only.

The attacker cannot establish persistence.

Security monitoring detects the attempted file modifications, the affected Pod is terminated, and Kubernetes automatically launches a clean replacement from the trusted container image.

Key Takeaways

After completing this lesson, you should understand:

What a Read-Only Root Filesystem is
Why immutable containers improve security
How writable filesystems increase risk
How Kubernetes enforces Read-Only Root Filesystems
Where applications should store writable data
Enterprise implementation strategies
Monitoring and workload hardening best practices

A Read-Only Root Filesystem is a core workload security control that protects running containers from unauthorized modification. Combined with Security Contexts, Pod Security Standards, non-root execution and immutable infrastructure practices, it greatly strengthens the security posture of Amazon EKS environments.

Knowledge Check

Question 1

What is the primary purpose of a Read-Only Root Filesystem?

A. Improve network performance
B. Prevent containers from modifying files in the root filesystem
C. Increase CPU allocation
D. Configure Kubernetes networking

Answer: B

Question 2

Which Kubernetes Security Context setting enables a Read-Only Root Filesystem?

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

Answer: C

Question 3

Where should applications store temporary writable data when using a Read-Only Root Filesystem?

A. Inside the container image
B. In writable volumes such as emptyDir or Persistent Volumes
C. In the /bin directory
D. In the Kubernetes API Server

Answer: B

Question 4

Which security benefit is provided by a Read-Only Root Filesystem?

A. Faster Pod scheduling
B. Prevention of malware persistence and unauthorized file modification
C. Automatic image scanning
D. Increased memory allocation

Answer: B

Question 5

Which combination represents enterprise best practice?

A. Writable root filesystem with privileged containers
B. Read-only root filesystem, non-root execution, disabled privilege escalation and writable mounted volumes only where required
C. Allow applications to install software at runtime
D. Store logs directly in the container image

Answer: B

What’s Next?

In the next lesson, you will learn about Privileged Containers, exploring why privileged mode is one of the highest-risk container configurations, how attackers abuse it to escape containers, and how enterprise organizations restrict privileged workloads in Amazon EKS using Pod Security Standards, admission policies and workload governance.

➡️ Next Lesson: Lesson 06 — Privileged Containers