tmpfs Mounts fuer sensible Daten in Docker richtig nutzen

1. Warum manche Daten nie auf die Festplatte duerfen

Standardmaessig landet jede Datei, die ein Container in sein beschreibbares Layer oder ein Volume schreibt, frueher oder spaeter auf der Festplatte des Docker-Hosts. Fuer die meisten Anwendungsdaten ist das genau richtig, weil sie den Neustart eines Containers ueberdauern sollen. Bei entschluesselten Secrets, temporaeren Session-Tokens oder Zwischenschluesseln fuer Verschluesselungsoperationen ist genau diese Persistenz jedoch ein Sicherheitsrisiko, weil sie im Klartext auf einem Datentraeger liegen bleiben, der bei einem Diebstahl der Festplatte oder einem forensischen Zugriff ausgelesen werden koennte.

tmpfs Mounts fuer sensible Daten loesen dieses Problem, indem sie ein Dateisystem ausschliesslich im Arbeitsspeicher bereitstellen, das beim Stoppen des Containers spurlos verschwindet. Ein Angreifer, der spaeter Zugriff auf die Festplatte erhaelt, findet dort keine Spur der ehemals im tmpfs abgelegten Daten, weil sie den Datentraeger nie erreicht haben. Die folgenden Abschnitte zeigen, wie tmpfs technisch funktioniert, wie es in Docker eingerichtet wird und wo die Grenzen dieses Sicherheitsmechanismus liegen.

Compliance-Anforderungen wie DSGVO oder PCI-DSS verlangen in vielen Faellen explizit, dass bestimmte Kategorien von Daten nicht laenger als noetig gespeichert werden duerfen, und in einigen Auslegungen sogar, dass hochsensible Daten wie Kreditkarten-Zwischenwerte niemals persistent abgelegt werden sollten. tmpfs Mounts fuer sensible Daten bieten hier einen technischen Nachweis, dass bestimmte Datenkategorien den Container niemals in persistenter Form verlassen, was Audits und Zertifizierungen erheblich vereinfachen kann.

2. Wie tmpfs technisch funktioniert

tmpfs ist ein Dateisystemtyp, der direkt im Linux-Kernel implementiert ist und Daten ausschliesslich im Arbeitsspeicher sowie optional im Swap-Bereich haelt, niemals aber dauerhaft auf einem Blockgeraet. Aus Sicht der Anwendung im Container verhaelt sich ein tmpfs Mount fuer sensible Daten wie ein ganz normales Verzeichnis, in das gelesen und geschrieben werden kann. Der entscheidende Unterschied liegt darin, was der Kernel im Hintergrund tut: Statt Seiten auf die Festplatte zu schreiben, verbleiben sie in Speicherseiten, die beim Unmounten oder beim Beenden des Containers freigegeben und ueberschrieben werden.

Diese Eigenschaft macht tmpfs nicht nur schnell, weil keine Festplatten-I/O anfaellt, sondern auch fluechtig im besten Sinne des Wortes: Ein Neustart des Hosts oder ein Container-Stopp loescht den Inhalt vollstaendig und unwiederbringlich. Fuer tmpfs Mounts fuer sensible Daten ist genau diese Fluechtigkeit das gewuenschte Verhalten, waehrend sie fuer normale Anwendungsdaten ein Ausschlusskriterium waere. Wer versehentlich Datenbank-Datendateien in ein tmpfs legt, verliert bei jedem Container-Neustart sämtliche Daten unwiderruflich.

3. tmpfs Mounts in Docker Run und Compose einrichten

Die Einrichtung eines tmpfs Mounts fuer sensible Daten erfolgt bei docker run ueber den Parameter --tmpfs, gefolgt vom Zielpfad im Container und optionalen Mount-Optionen. In Docker Compose geschieht dasselbe deklarativ ueber den Schluessel tmpfs in der Service-Definition, entweder als einfache Liste von Pfaden oder als ausfuehrlichere Mount-Syntax mit zusaetzlichen Parametern wie Groesse und Berechtigungsmodus. Beide Varianten fuehren zum selben Ergebnis: ein In-Memory-Dateisystem, das beim naechsten Container-Start wieder leer ist.

Ein haeufiger Anwendungsfall fuer tmpfs Mounts fuer sensible Daten ist das Ablegen entschluesselter Konfigurationsdateien, die eine Anwendung beim Start aus einem verschluesselten Secret-Store entschluesselt und danach nur noch im tmpfs vorhaelt. So bleibt der entschluesselte Klartext niemals dauerhaft auf der Festplatte, selbst wenn die Anwendung selbst keine spezielle In-Memory-Handhabung fuer Secrets implementiert.

#!/usr/bin/env bash
# tmpfs-run.sh — mounting a tmpfs for decrypted secrets
set -euo pipefail

docker run -d --name app \
  --tmpfs /run/secrets-decrypted:rw,noexec,nosuid,size=64m,mode=0700 \
  mironsoft/app:latest

# Verify the mount is tmpfs, not a regular volume
docker exec app mount | grep secrets-decrypted
# tmpfs on /run/secrets-decrypted type tmpfs (rw,nosuid,noexec,size=65536k,mode=700)

# docker-compose.yml — declarative tmpfs mount for sensitive session data
services:
  app:
    image: mironsoft/app:latest
    tmpfs:
      - /run/secrets-decrypted:rw,noexec,nosuid,size=64m,mode=0700
      - /tmp/sessions:rw,size=128m,mode=1700
    environment:
      SECRET_DECRYPT_TARGET: /run/secrets-decrypted/config.json

4. Groessenlimits und Speicherverbrauch kontrollieren

Ohne explizites Groessenlimit kann ein tmpfs Mount fuer sensible Daten theoretisch bis zur Haelfte des verfuegbaren Arbeitsspeichers wachsen, was auf einem Host mit mehreren Containern schnell zu Speicherdruck und im schlimmsten Fall zum Out-of-Memory-Killer des Kernels fuehren kann. Der Parameter size= begrenzt den maximal belegbaren Speicher pro Mount und sollte bei jedem produktiven tmpfs-Einsatz explizit gesetzt werden, angepasst an die tatsaechlich erwartete Datenmenge.

Ein zu knapp bemessenes Limit fuehrt dazu, dass Schreiboperationen mit ENOSPC fehlschlagen, sobald die Grenze erreicht ist, genau wie bei einer vollen Festplatte. Ein zu grosszuegiges Limit hingegen nimmt dem Betriebssystem Handlungsspielraum, falls mehrere Container gleichzeitig Speicher beanspruchen. Fuer tmpfs Mounts fuer sensible Daten wie entschluesselte Konfigurationsdateien oder Session-Tokens reichen in der Praxis meist wenige Megabyte bis niedrige zweistellige Megabyte-Bereiche aus, waehrend groessere Zwischenergebnisse entsprechend hoehere Limits benoetigen.

#!/usr/bin/env bash
# monitor-tmpfs-usage.sh — check current tmpfs memory consumption
set -euo pipefail

CONTAINER="app"

# Show tmpfs mount usage from inside the container
docker exec "$CONTAINER" df -h /run/secrets-decrypted

# Cross-check against the size= limit configured for the mount
docker inspect "$CONTAINER" \
  --format '{{ range .Mounts }}{{ if eq .Type "tmpfs" }}{{ .Destination }} -> {{ .RW }}{{ end }}{{ end }}'

echo "[INFO] Compare 'Used' column against the configured size= limit"

5. Berechtigungen und Mount-Optionen fuer sensible Daten

Neben der Groesse sollten tmpfs Mounts fuer sensible Daten auch mit restriktiven Berechtigungen und Mount-Optionen versehen werden. Die Option mode=0700 stellt sicher, dass nur der Eigentuemer des Verzeichnisses lesen und schreiben darf, waehrend noexec verhindert, dass Dateien im tmpfs als ausfuehrbare Programme gestartet werden koennen, ein wichtiger Schutz gegen bestimmte Angriffsmuster, bei denen ein Angreifer versucht, Schadcode in einen beschreibbaren Bereich zu schreiben und danach auszufuehren.

Die Option nosuid ergaenzt diesen Schutz, indem sie verhindert, dass SUID- oder SGID-Bits auf Dateien im tmpfs beim Ausfuehren beruecksichtigt werden, selbst wenn noexec aus irgendeinem Grund nicht gesetzt werden kann. Diese Kombination aus restriktiven Berechtigungen und Mount-Optionen macht einen tmpfs Mount fuer sensible Daten nicht nur fluechtig, sondern auch gehaertet gegen typische Ausnutzungsversuche, sollte ein Angreifer bereits Codeausfuehrung im Container erreicht haben.

#!/usr/bin/env bash
# verify-tmpfs-hardening.sh — confirm restrictive mount options are active
set -euo pipefail

docker run --rm \
  --tmpfs /secure:rw,noexec,nosuid,nodev,size=32m,mode=0700 \
  alpine sh -c '
    mount | grep /secure
    touch /secure/test.sh
    echo "echo pwned" > /secure/test.sh
    chmod +x /secure/test.sh
    /secure/test.sh || echo "[OK] Execution blocked by noexec"
  '

6. Typische Anwendungsfaelle: Secrets, Sessions, Zwischenergebnisse

Der klassischste Anwendungsfall fuer tmpfs Mounts fuer sensible Daten ist die kurzfristige Ablage entschluesselter Secrets, die eine Anwendung beim Start aus einem Vault- oder KMS-System bezieht. Statt die entschluesselten Werte direkt als Umgebungsvariablen zu setzen, die in Prozesslisten und Debug-Ausgaben sichtbar werden koennen, schreibt die Anwendung sie in eine Datei im tmpfs und liest sie von dort, was das Risiko einer versehentlichen Offenlegung deutlich reduziert.

Ein zweiter haeufiger Anwendungsfall sind Session-Daten in Webanwendungen, die aus Performance-Gruenden nicht in einer externen Session-Datenbank, sondern lokal im Container gehalten werden sollen, aber gleichzeitig nicht auf der Festplatte landen duerfen, weil sie personenbezogene Daten enthalten. Auch temporaere Zwischenergebnisse kryptografischer Operationen, etwa entschluesselte Zertifikatsschluessel fuer TLS-Terminierung, profitieren von tmpfs Mounts fuer sensible Daten, weil sie nur fuer die Laufzeit des Containers existieren muessen und danach spurlos verschwinden sollen.

Ein weiterer, weniger offensichtlicher Anwendungsfall ist die Zwischenspeicherung von Uploads waehrend der Verarbeitung, bevor sie verschluesselt in einen dauerhaften Speicher wandern. Eine Anwendung, die hochgeladene Dokumente zunaechst virenscannt und danach verschluesselt ablegt, kann die unverschluesselte Zwischenversion in einem tmpfs Mount fuer sensible Daten halten, sodass zu keinem Zeitpunkt eine unverschluesselte Kopie dauerhaft auf der Festplatte liegt.

7. Grenzen von tmpfs: was es nicht loest

So nuetzlich tmpfs Mounts fuer sensible Daten sind, sie loesen nicht jedes Sicherheitsproblem rund um Secrets. Ein Angreifer, der bereits Codeausfuehrung im laufenden Container erreicht hat, kann den Inhalt eines tmpfs genauso auslesen wie jeden anderen beschreibbaren Bereich, weil das Betriebssystem innerhalb des Containers keinen Unterschied zwischen tmpfs und einem regulaeren Verzeichnis macht, ausser bei der Frage, wohin die Daten letztlich geschrieben werden. tmpfs schuetzt vor Offline-Angriffen auf die Festplatte, nicht vor Angriffen auf einen laufenden, kompromittierten Prozess.

Ausserdem loest tmpfs keine Probleme rund um die sichere Uebertragung von Secrets in den Container hinein. Wenn ein Secret ueber eine unverschluesselte Umgebungsvariable oder eine Datei ausserhalb des tmpfs in den Container gelangt, bevor es dort abgelegt wird, bleibt die urspruengliche Uebertragung ein potenzielles Risiko. tmpfs Mounts fuer sensible Daten sind ein Baustein in einer umfassenderen Secrets-Management-Strategie, kein Ersatz fuer Docker Secrets, Vault-Integrationen oder verschluesselte Uebertragungswege.

8. Swap-Verhalten und die Grenzen der Fluechtigkeit

Ein oft uebersehener Aspekt von tmpfs Mounts fuer sensible Daten ist, dass der Linux-Kernel unter Speicherdruck tmpfs-Seiten in den Swap-Bereich auslagern kann, sofern Swap auf dem Host aktiviert ist. Sobald das passiert, landen die vermeintlich fluechtigen Daten doch auf einem Blockgeraet, naemlich der Swap-Partition oder Swap-Datei, und koennten dort nach einem Neustart oder bei einem forensischen Zugriff wiederhergestellt werden.

Fuer produktive Umgebungen mit besonders hohen Sicherheitsanforderungen an tmpfs Mounts fuer sensible Daten ist es deshalb ratsam, entweder Swap auf dem Host komplett zu deaktivieren oder verschluesselten Swap einzurichten, der die potenziell auf Swap ausgelagerten Daten transparent verschluesselt. Alternativ hilft ein ausreichend dimensioniertes size=-Limit dabei, den Speicherdruck von vornherein gering zu halten, sodass der Kernel seltener auf Swapping zurueckgreifen muss.

Ein einfacher Test, ob Swap auf dem Docker-Host aktiv ist, laesst sich mit swapon --show durchfuehren. Liefert der Befehl eine Ausgabe, ist mindestens ein Swap-Bereich aktiv, und die Fluechtigkeitsgarantie eines tmpfs Mounts fuer sensible Daten ist nicht mehr uneingeschraenkt gegeben. In Kubernetes-Umgebungen ist Swap standardmaessig ohnehin deaktiviert, was tmpfs dort von Haus aus zu einer robusteren Wahl macht als auf einem klassischen Docker-Host mit aktivem Swap.

9. tmpfs im Vergleich zu anderen Mount-Typen

Um die Rolle von tmpfs Mounts fuer sensible Daten besser einzuordnen, lohnt sich ein direkter Vergleich mit den anderen gaengigen Mount-Typen in Docker.

Die Tabelle macht deutlich, dass tmpfs der einzige Mount-Typ unter den vieren ist, der Daten grundsaetzlich nicht auf die Festplatte schreibt. Fuer alle Daten, bei denen genau diese Eigenschaft gefordert ist, bleiben tmpfs Mounts fuer sensible Daten die richtige, einfache Loesung, ohne zusaetzliche Verschluesselungssoftware oder externe Secret-Stores fuer den reinen Laufzeit-Zustand einrichten zu muessen.

In der Praxis kombinieren die meisten produktiven Setups mehrere Mount-Typen gleichzeitig: ein Named Volume fuer die eigentlichen Anwendungsdaten, ein tmpfs fuer entschluesselte Secrets und Sessions, sowie gelegentlich einen Bind Mount fuer Konfigurationsdateien, die aus dem Repository stammen. Diese Kombination nutzt fuer jede Datenkategorie den jeweils passenden Mount-Typ, statt eine einzige Loesung fuer alle Anforderungen zu erzwingen.

10. Zusammenfassung

tmpfs Mounts fuer sensible Daten stellen In-Memory-Dateisysteme bereit, die niemals auf die Festplatte des Docker-Hosts geschrieben werden und beim Container-Stopp spurlos verschwinden. Sie eignen sich hervorragend fuer entschluesselte Secrets, Session-Tokens und temporaere kryptografische Zwischenergebnisse, sollten aber immer mit Groessenlimits, restriktiven Berechtigungen und den Optionen noexec sowie nosuid versehen werden.

Wichtig ist, die Grenzen dieses Mechanismus zu kennen: tmpfs schuetzt vor Offline-Angriffen auf die Festplatte, nicht vor einem bereits kompromittierten laufenden Prozess, und kann unter Speicherdruck auf Swap ausgelagert werden, sofern Swap aktiviert ist. tmpfs Mounts fuer sensible Daten sind ein wichtiger Baustein, aber kein vollstaendiger Ersatz fuer eine umfassende Secrets-Management-Strategie.

11. FAQ: tmpfs Mounts fuer sensible Daten