Read-only Root Filesystem: Best Practices und typische Breakages

Ein read-only Root Filesystem ist eine bewährte Sicherheitsmaßnahme für Container, um unbeabsichtigte Änderungen am System zu verhindern und die Angriffsfläche zu minimieren. Durch die Einschränkung des Root-Dateisystems auf nur-Lese-Zugriff wird das Risiko von Manipulationen an kritischen Systemdateien stark reduziert. Gleichzeitig kann dies jedoch zu Problemen führen, wenn Anwendungen Schreibzugriffe auf Pfade im Root-Filesystem erwarten. In diesem Artikel betrachten wir Best Practices, typische Fallstricke und Strategien, um Read-only Root Filesysteme erfolgreich in Docker Compose und anderen Container-Umgebungen zu betreiben.

1. Vorteile eines Read-only Root Filesystems

Die zentrale Motivation für ein read-only Root FS liegt in der Sicherheit und Stabilität von Containern:

• Schutz kritischer Systemdateien vor Manipulationen.
• Reduzierung der Angriffsfläche bei Exploits.
• Erhöhte Konsistenz zwischen Container-Starts, da keine persistente Änderung am Image erfolgt.
• Verbesserung der Auditierbarkeit von Containern.

Sicherheitsaspekte

Ein read-only Root verhindert, dass Angreifer oder kompromittierte Prozesse Kernel- oder Systemdateien verändern können. Zusammen mit Capabilities, seccomp und SELinux/AppArmor entsteht eine robuste Sicherheitsarchitektur.

2. Aktivierung in Docker und Compose

Docker erlaubt es, das Root-Filesystem eines Containers über das Flag --read-only als nur-Lese zu mounten. In Docker Compose kann dies direkt in der Service-Definition umgesetzt werden.

Beispiel Docker CLI

docker run --rm --read-only -it ubuntu:22.04 bash

Beispiel Docker Compose

version: "3.8"
services:
  app:
    image: myapp:latest
    read_only: true
    tmpfs:
      - /tmp
      - /var/tmp

Hier wird read_only: true gesetzt, und temporäre Verzeichnisse werden per tmpfs bereitgestellt, damit Schreiboperationen für /tmp und /var/tmp weiterhin möglich sind.

3. Schreibzugriffe außerhalb des Root-Filesystems

Viele Anwendungen erwarten Schreibzugriffe in bestimmten Pfaden. Bei einem read-only Root müssen diese Pfade explizit als beschreibbar bereitgestellt werden.

Typische writable Pfade

• /tmp und /var/tmp → temporäre Dateien
• /var/log → Logfiles
• /run oder /var/run → Runtime-Dateien wie PID-Files oder Sockets
• /home/benutzer → falls User-Daten innerhalb des Containers liegen

Strategien

• tmpfs für temporäre Pfade: schnelle RAM-basierte Dateien, automatisch gelöscht bei Container-Stopp.
• Volumes für persistente Daten: Logs, Configs, Uploads.
• Separate writable Layer nur für notwendige Pfade, kein generelles Beschreiben des Root FS.

4. Typische Breakages und Fehlerquellen

Ein read-only Root FS kann diverse Probleme verursachen, wenn Anwendungen unerwartete Schreibzugriffe ausführen:

Fehlerquellen

• Logs im Root-Filesystem (z.B. /var/log/app.log)
• Temporäre Dateien oder Lock-Files in /tmp oder /var/run
• Package Manager oder Init-Skripte, die Runtime-Dateien schreiben
• Shell-Skripte oder Startup-Mechanismen, die Caches erzeugen

Fehlerbeispiel

touch /var/log/app.log
touch: cannot touch '/var/log/app.log': Read-only file system

Solche Fehler lassen sich durch tmpfs oder Docker Volumes lösen.

5. Best Practices für produktive Container

• Nur explizit notwendige Pfade beschreibbar machen.
• Verwendung von tmpfs für temporäre Daten und Sockets.
• Logs per Volume in Host oder externe Logging-Lösung auslagern.
• Init-Container oder Entrypoint-Skripte anpassen, um fehlende writable Pfade vor Container-Start zu erzeugen.
• Automatische Tests mit read-only Root durchführen, um Breakages frühzeitig zu erkennen.
• Kombination mit Security Hardening: Capabilities einschränken, seccomp Profile, AppArmor/SELinux nutzen.

6. Monitoring und Debugging

Wenn Container mit read-only Root FS scheitern, helfen folgende Schritte:

• Container starten mit interaktivem Bash

  docker run --rm --read-only -it myapp:latest bash

• tmpfs prüfen:

  mount | grep tmpfs

• Logs prüfen und Volumes mounten:

  docker logs <container>

• Testen, ob Schreibzugriffe an temporären Pfaden funktionieren:

  echo test > /tmp/testfile

7. Kombination mit Docker Compose Patterns

In Compose kann read-only Root mit Multi-Stage Build Images, tmpfs und Volumes kombiniert werden, um robuste, produktive Deployments zu ermöglichen:

version: "3.8"
services:
  web:
    image: myapp:prod
    read_only: true
    tmpfs:
      - /tmp
      - /var/tmp
    volumes:
      - logs:/var/log/app
      - data:/var/lib/app
volumes:
  logs:
  data:

So bleiben Root-Dateien unverändert, während Logs und persistente Daten weiterhin beschreibbar bleiben.

8. Zusammenfassung

Ein read-only Root Filesystem erhöht die Sicherheit und Konsistenz von Containern. Erfolgreiches Hardening erfordert jedoch eine bewusste Planung von temporären Pfaden, Logs und persistenter Speicherung. Durch die Kombination von tmpfs, Volumes und angepassten Entrypoint-Skripten können typische Breakages vermieden werden. In Verbindung mit Security-Maßnahmen wie Capabilities, seccomp und Mandatory Access Control Mechanismen entsteht eine robuste, sichere Container-Architektur für produktive Umgebungen.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.