Sicherheit in Docker-Umgebungen

Container-Technologie bringt einen Sicherheitsvorteil: Anwendungen sind voneinander isoliert. Aber sie bringt auch neue Risiken: Wer Docker falsch betreibt, baut sich Sicherheitslöcher, die in einer klassischen VM-Umgebung nicht möglich wären. Anders als bei VMs (mit separatem Gastkernel und Hypervisor-Grenze) teilen sich Container den Host-Kernel – eine Kernel-Lücke kann theoretisch zum Container-Breakout führen. Und in der Praxis sind viele Docker-Installationen aus Bequemlichkeit unsicher konfiguriert: Container als Root, unbeschränkte Capabilities, ungescannte Public-Images, freier Daemon-Socket. Diese Lektion zeigt die wichtigsten Angriffsvektoren und die Härtungsmaßnahmen, die in jede produktive Docker-Umgebung gehören.

Die Analogie: Stell dir vor, dein Container-Host ist ein Hochhaus mit Mietwohnungen. Jeder Mieter (Container) hat seine eigene Wohnung mit eigenem Schloss – das ist die Grundisolation. Aber Wasser, Strom und Heizung (Kernel) sind zentral. Ein Mieter, der den Trick kennt, kann durch die Versorgungsschächte in andere Wohnungen kommen. Außerdem: Wenn die Eingangstür zum Haus offensteht (Daemon-Socket) und die Mieter selbst Hausverbote aussprechen können (Root-Berechtigung), wird es richtig gefährlich.

1) Die wichtigsten Angriffsflächen

Bevor man härtet, sollte man die Schwachstellen kennen. Hier die häufigsten Risiken in Docker-Umgebungen – mit jeweils einer Sofortmaßnahme:

Häufigste Sicherheitslücken in Docker-Umgebungen

1. Container als Root

Default-Behavior: Anwendung läuft als root im Container. Bei Container-Escape: Root auf Host.

USER 1000 im Dockerfile

2. Privileged Mode

--privileged hebt alle Capabilities auf, gibt vollen Hardware-Zugriff. Quasi Root-Shell auf dem Host.

nie nutzen, --cap-add gezielt

3. Docker-Socket gemountet

Wer /var/run/docker.sock im Container hat, kann Container starten = effektiv Root auf Host.

Socket niemals mounten

4. Ungescannte Public Images

Image aus Docker Hub mit alten Base-Layern: ungepatchte CVEs in OpenSSL, glibc etc.

Trivy-Scan in CI/CD

5. Secrets in Image / ENV

API-Keys, Passwörter im Dockerfile oder als ENV-Variable → in Image-Layer dauerhaft sichtbar.

Secrets Mount / Vault

6. Latest-Tag in Produktion

nginx:latest kann sich ändern – unkontrollierte Updates = unkontrollierbare Sicherheits-Drift.

Pin auf SHA-Digest

7. Unbegrenzte Ressourcen

Ein Container, der CPU/RAM ausschöpft, kann andere Container und Host lahmlegen (DoS).

--memory, --cpus setzen

8. Standard Bridge ohne Segmentierung

Alle Container in einem Netz – lateral movement möglich, wenn ein Container kompromittiert wird.

Custom Networks pro Trust-Zone

Diese acht Schwachstellen tauchen in jedem zweiten Docker-Audit auf. Keine davon braucht teure Werkzeuge zur Behebung – nur Bewusstsein und Disziplin im Setup. Mehr zu allgemeinen Sicherheitsprinzipien in CIA-Triad und Privileged Access Management.

2) Hardening-Checkliste – wie sicher ist dein Container-Setup?

Hak ab, was bei dir umgesetzt ist. Der Score zeigt deinen Härtungsgrad. Praxis: Wer alle Punkte abgehakt hat, ist deutlich besser als 95 % der Docker-Installationen da draußen:

Container-Hardening-Checkliste (interaktiv)

✓

Non-Root-User im Container

Dockerfile enthält USER 1000 oder ähnliches; docker exec id zeigt nicht uid=0.

✓

Read-Only-Filesystem

Container startet mit --read-only; nur explizit benötigte Pfade als --tmpfs oder Volume beschreibbar.

✓

Capabilities reduziert

--cap-drop ALL als Default, dann gezielt --cap-add NET_BIND_SERVICE etc. Keine privilegierten Container.

✓

Ressourcen-Limits gesetzt

--memory 512m --cpus 1.0 verhindert, dass ein Container den Host lahmlegt.

✓

Image-Versionen gepinnt

Keine :latest in Produktion. Idealerweise SHA-Digest (nginx@sha256:...) für 100 % Reproduzierbarkeit.

✓

Image-Scanning in CI/CD

Trivy/Grype/Snyk scannt jedes Image vor dem Push. Pipeline schlägt fehl bei HIGH/CRITICAL-CVEs.

✓

Secrets nicht im Image

Keine API-Keys oder Passwörter in Dockerfile, ENV oder Image-Layern. Secrets per Runtime-Mount oder Vault.

✓

Netzwerk-Segmentierung

Custom Networks für Frontend/Backend/DB. DB nur im internen Netz, keine Port-Mappings.

✓

Docker-Socket nicht gemountet

Kein Container hat Zugriff auf /var/run/docker.sock. Falls doch nötig (Watchtower etc.): über Socket-Proxy.

✓

Logging und Monitoring

Container-Logs werden zentral gesammelt (Loki, ELK), Anomalien geben Alerts. Siehe Log-Analyse.

Härtungsgrad

0 / 10

Wenn du in einer realen Umgebung weniger als 7/10 Punkte hast, ist akuter Handlungsbedarf – jede einzelne Lücke kann der Eintrittspunkt für einen erfolgreichen Angriff sein. Mehrere zusammen = praktisch garantierter Vorfall.

3) Vorher / Nachher – ein unsicheres Dockerfile fixen

Sicherheits-Konzepte werden konkret, wenn man sie an Code sieht. Hier ein typisches unsicheres Dockerfile aus dem Web – und die gehärtete Version daneben:

Dockerfile vor und nach dem Härten

✗ Unsicher (häufig im Web)

FROM node:latest # läuft als root, Image-Größe unbekannt WORKDIR /app COPY . . ENV DB_PASSWORD=geheim123 # Secret hart kodiert! RUN npm install # installiert auch dev-deps EXPOSE 3000 CMD ["npm", "run", "dev"] # läuft als root, nodemon

✓ Gehärtet

FROM node:20.11.0-alpine3.19 # gepinnt, klein (~180 MB) WORKDIR /app COPY --chown=1000:1000 package*.json ./ RUN npm ci --only=production COPY --chown=1000:1000 . . # neuer User mit fester UID USER 1000:1000 EXPOSE 3000 # HEALTHCHECK fürs Monitoring HEALTHCHECK --interval=30s \ CMD curl -f http://localhost:3000/health || exit 1 CMD ["node", "server.js"] # Secrets via ENV zur Laufzeit

Beim docker run kommen dann die Runtime-Härtungen dazu: docker run --read-only --tmpfs /tmp --cap-drop ALL --memory 512m --cpus 1.0 -e DB_PASSWORD=$DB_PASSWORD myapp. Aus einem typischen Quick-Hack wird so ein produktionsreifes Setup. Mehr zu Härtung allgemein in Dependency Management.

4) Capabilities – das mächtigere „chmod 600"

Auf Linux hat Root viel Macht. Aber genau betrachtet ist „Root" eine Sammlung von Capabilities – einzelne Berechtigungen wie „Netzwerk konfigurieren", „neue Mount-Points anlegen", „Privileg-erhöhende Syscalls aufrufen". Docker-Container haben standardmäßig nicht alle Capabilities – aber genug, um zu mehr Schaden anzurichten als nötig. Best Practice: Alle Capabilities droppen, nur die wirklich nötigen explizit hinzufügen.

Capability	Wofür	Standardmäßig im Container?
`NET_BIND_SERVICE`	Bind auf Ports < 1024	Ja (kann meist gedroppt werden)
`CHOWN`	Eigentümerschaft von Dateien ändern	Ja
`SETUID` / `SETGID`	User/Group des Prozesses ändern	Ja
`SYS_ADMIN`	Viele Admin-Tasks (mount, ptrace…)	NEIN (gefährlich!)
`NET_ADMIN`	Netzwerk konfigurieren	NEIN
`SYS_PTRACE`	Prozesse anderer User debuggen	NEIN

Praxis: für einen Webserver-Container reicht --cap-drop ALL --cap-add NET_BIND_SERVICE. Damit kann der Container auf Port 80 binden, aber sonst praktisch nichts Privilegiertes mehr machen. Wenn ein Angreifer ausbricht, hat er keine Tools mehr.

5) Secrets-Management – wo gehören Passwörter hin?

Eine der häufigsten Sünden: API-Keys, DB-Passwörter, JWT-Secrets im Image. Sobald das Image in einer Registry liegt, kann jeder, der Pull-Access hat, das Secret extrahieren. Auch ENV-Variablen sind nicht sicher – sie tauchen in docker inspect auf, in Logs, in Crash-Reports. Die korrekten Methoden:

Docker Secrets (in Swarm-Mode): Secrets werden verschlüsselt im Raft-Cluster gespeichert, im Container nur als read-only Datei in /run/secrets/.
Kubernetes Secrets (in K8s): ähnliches Prinzip, base64-codiert im etcd. Mit Encryption-at-Rest und RBAC.
HashiCorp Vault, AWS Secrets Manager, Azure Key Vault: dedizierte Secret-Management-Systeme. Container holt Secrets zur Laufzeit per API.
BuildKit Secrets (während des Builds): --mount=type=secret erlaubt Secret-Nutzung beim Build, ohne dass es im Image landet (z. B. Private-Registry-Auth für npm install).
External Secrets Operator: in K8s eine Brücke zwischen externen Secret-Stores und K8s-Secrets.

Wichtige Regel: Secrets niemals in Git committen, niemals im Image-Layer, niemals via ENV in produktiv laufenden Containern wenn vermeidbar. Mehr zu Secrets in Dependency Management und DSGVO TOMs.

6) Image-Signing und Supply-Chain-Sicherheit

Eine weitere Schicht der Container-Sicherheit ist die Supply Chain: Wie weißt du, dass das Image, das du pullst, wirklich von dem stammt, der drauf steht? Ohne zusätzliche Schritte: gar nicht. Drei Mechanismen härten die Supply Chain:

Image-Signing mit Cosign / Sigstore: Images werden mit privatem Schlüssel signiert, vor dem Pull verifiziert. Kann in Kubernetes per Admission Controller erzwungen werden.
SBOM (Software Bill of Materials): Liste aller Komponenten im Image. Erlaubt schnelle Antwort auf Fragen wie „Sind wir von log4shell betroffen?". Tools: Syft, Trivy.
Provenance Attestations (SLSA): Beweise, wer das Image wann und mit welchen Inputs gebaut hat. Schutz gegen Build-Pipeline-Angriffe.

Diese Themen sind die jüngere Frontlinie der Container-Sicherheit, getrieben durch Vorfälle wie SolarWinds (2020) und Log4Shell (2021). Behörden wie der amerikanische CISA fordern sie inzwischen für Software, die der Bundesregierung verkauft wird. In Deutschland ist BSI TR-03183 die analoge Anforderung. Mehr in BSI-Grundschutz.

7) Rootless Docker, Podman und gVisor

Eine weitere Härtungsstufe: Den Docker-Daemon selbst entrechten. Der traditionelle dockerd läuft als Root – das ist nötig, um Namespaces, iptables und Cgroups zu manipulieren. Aber: Root-Daemon ist ein riesiges Angriffsziel.

Rootless Docker: Daemon läuft als normaler User, nutzt User-Namespaces für Container. Einschränkungen: keine Ports < 1024, kein overlay-Netzwerk, manche Storage-Driver fehlen. Aber: Viel kleinere Angriffsfläche.
Podman: Alternative zu Docker. Kein zentraler Daemon, jeder Container ist ein eigener Prozess. CLI ist kompatibel (alias docker=podman funktioniert in den meisten Fällen). Default rootless. Standardmäßig in modernen Red-Hat-/Fedora-Distributionen.
gVisor: Ein User-Space-Kernel zwischen Container und Host. Container-Syscalls werden von gVisor abgefangen statt direkt am Host-Kernel ausgeführt. Höhere Isolation, etwas niedrigere Performance. Wird z. B. von Google in Cloud Run eingesetzt.
Kata Containers: Jeder Container läuft in einer minimalen, leichten VM. Vereint die Sicherheit von VMs mit der Bedienbarkeit von Containern. Etwas mehr Overhead, aber bei Mehrmandanten-Workloads (Cloud-Provider) Standard.

Für die meisten Unternehmenskontexte reicht klassisches Docker mit den oben genannten Härtungen aus. Aber wer sehr sensible Workloads oder echte Multi-Tenancy (verschiedene Kunden auf gleicher Hardware) hat, sollte über diese Alternativen nachdenken. In der IHK-Prüfung wird gefragt, ob du die Begriffe einsortieren kannst – tiefere Details sind eher Praxis-Spezialisten-Wissen.

Zusammenfassung

Container-Sicherheit unterscheidet sich grundlegend von VM-Sicherheit, weil Container den Host-Kernel teilen. Die wichtigsten Schwachstellen: Container als Root, Privileged Mode, gemounteter Docker-Socket, ungescannte Images, Secrets im Image, latest-Tags, fehlende Ressourcen-Limits, fehlende Netzwerk-Segmentierung. Härtungsmaßnahmen: Non-Root-User (USER 1000), Read-Only-Filesystem (--read-only + --tmpfs), Capabilities reduzieren (--cap-drop ALL --cap-add NET_BIND_SERVICE), Ressourcen-Limits (--memory --cpus), gepinnte Image-Versionen, Image-Scanning in CI/CD, Secrets via Vault/K8s-Secrets/BuildKit-Secrets statt im Image, Netzwerk-Segmentierung mit Custom Bridges. Supply-Chain-Sicherheit: Image-Signing (Cosign), SBOM (Syft), Provenance (SLSA). Härtere Alternativen zu klassischem Docker: Rootless Docker, Podman (kein Daemon), gVisor (User-Space-Kernel), Kata Containers (Mini-VM pro Container) – letzteres für Multi-Tenancy-Workloads. Eine Hardening-Checkliste sollte in jede DevOps-Pipeline integriert sein.