Writable Container Root Filesystem in Kubernetes

Medium Risk infrastructure-security

kubernetescontainer-securityfilesystem-securityrcepersistenceread-only-filesystemimmutable-infrastructure

What it is

Kubernetes containers running with writable root filesystems enable attackers to persist malicious code, modify system binaries, alter runtime behavior, and facilitate lateral movement after compromising applications. This vulnerability allows persistent attacks and makes forensic analysis difficult by enabling evidence tampering.

Language:

# VULNERABLE: Containers with writable root filesystems

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-application
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: app-container
        image: myapp:1.0.0
        ports:
        - containerPort: 8080
        # VULNERABLE: No securityContext or readOnlyRootFilesystem not set
        # Container can write to root filesystem
        
      - name: sidecar-container
        image: sidecar:latest
        securityContext:
          runAsNonRoot: true
          # VULNERABLE: readOnlyRootFilesystem not specified
          # Defaults to writable filesystem

# SECURE: Containers with read-only root filesystems

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-application
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: app-container
        image: myapp:1.0.0
        ports:
        - containerPort: 8080
        securityContext:
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          allowPrivilegeEscalation: false
        volumeMounts:
        - name: tmp-volume
          mountPath: /tmp
        - name: cache-volume
          mountPath: /app/cache
          
      - name: sidecar-container
        image: sidecar:latest
        securityContext:
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          allowPrivilegeEscalation: false
        volumeMounts:
        - name: logs-volume
          mountPath: /var/log
          
      volumes:
      - name: tmp-volume
        emptyDir: {}
      - name: cache-volume
        emptyDir: {}
      - name: logs-volume
        emptyDir: {}

💡 Why This Fix Works

The vulnerable configuration omits readOnlyRootFilesystem in the security context, allowing containers to write to the root filesystem and persist malicious code. The secure version sets readOnlyRootFilesystem: true and provides explicit emptyDir volumes for paths requiring write access (/tmp, /app/cache, /var/log), preventing filesystem-based persistence attacks.

Why it happens

Kubernetes containers run with fully writable root filesystems by default when no securityContext is configured. This insecure default allows attackers who compromise applications to persist malicious code, modify system binaries, and tamper with evidence.

Root causes

Default Writable Filesystem

Missing Read-Only Configuration

Container specifications don't explicitly set readOnlyRootFilesystem: true in security contexts. Without this explicit configuration, containers inherit the writable default, providing attackers with persistent storage for malicious payloads.

Legacy Application Write Requirements

Applications are designed to write to system directories like /tmp, /var, or application directories within the container filesystem. Rather than refactoring with volume mounts, teams allow writable root filesystems for backward compatibility.

Incomplete Volume Mount Implementation

Pod specifications lack appropriate volume mounts (emptyDir, persistent volumes) for directories that legitimately require write access. Without proper volumes, applications can't function with read-only root filesystems.

Insufficient Security Knowledge

Developers and operators are unaware of immutable infrastructure best practices and read-only filesystem security benefits. Teams don't realize the significant security improvements gained by restricting filesystem modifications.

Fixes

Enable Read-Only Root Filesystem

Set readOnlyRootFilesystem: true in the securityContext of all container specifications. This makes the container's root filesystem immutable, preventing malicious code persistence and system file tampering after application compromise.

Mount Volumes for Writable Paths

Use explicit volumeMounts and volumes configuration for directories that legitimately require write access. Map emptyDir or persistent volumes to specific paths, providing targeted write access without compromising overall filesystem immutability.

Provide Temporary Directory Volumes

Mount emptyDir volumes for /tmp, /var/tmp, and other temporary directories where applications need to write transient data. EmptyDir provides temporary writable space that's cleaned up when pods terminate.

Implement Persistent Storage

Use PersistentVolumes or PersistentVolumeClaims for application data requiring persistence across pod restarts. Mount these volumes to specific application data paths, separating persistent data from the read-only system filesystem.

Configure Logging Volumes

If applications write logs to local filesystem paths like /var/log, mount emptyDir or persistent volumes to these locations. Better yet, refactor applications to log to stdout/stderr for container-native logging.

Test Read-Only Compatibility

Thoroughly test applications with read-only root filesystems in staging environments before production deployment. Identify all paths requiring write access and add appropriate volume mounts to address application requirements.

Detect This Vulnerability in Your Code

Sourcery automatically identifies writable container root filesystem in kubernetes and many other security issues in your codebase.

Scan Your Code for Free Explore More Vulnerabilities