Warum manche Enterprises Docker immer noch verbieten (und was Devs dagegen tun)
Wenn Sie denken, Container-Technologie ist mittlerweile überall, liegen Sie größtenteils richtig — aber nicht überall. Immer wieder berichten Entwickler bei großen regulierten Organisationen — Banken, Versicherern, großen Gesundheitsunternehmen —, dass sie Docker (oder lokale Container) in ihrer täglichen Dev-Arbeit schlicht nicht nutzen können. Und ja, das überrascht. Besonders weil wir ständig hören, Container seien der Standard-Baustein moderner Software. Also: Was ist da los? Und wie umgehen Dev-Teams das?
Das Verbot kommt häufiger vor, als Sie denken
Ich bin auf einen Thread gestoßen, in dem jemand bei einer Bank erzählte, dem Offshore-Dev-Team sei es untersagt, Docker (und jede Virtualisierung) innerhalb ihrer virtuellen Desktops auszuführen. Ein Entwickler kommentierte:
"Das ist häufiger, als man denkt... die letzten drei Finanzunternehmen, bei denen ich war, machen kein Docker oder irgendetwas Ähnliches."
Andere stimmten zu:
"Ziemlich üblich bei Banken. Selbst bei der NASA ist Docker nicht erlaubt. Nur Podman."
Während die vorherrschende Botschaft also "Container überall" lautet, sieht die Realität in bestimmten Branchen so aus: "keine lokalen Container, danke".
Warum der Widerstand? Es läuft auf drei große Themen hinaus
1. Sicherheits- und Compliance-Aufwand
Container mögen wie eine Bequemlichkeit für Entwickler wirken — aber aus Sicht eines reifen Enterprise sind sie eine weitere Angriffsfläche. Zum Beispiel:
Eine Container-Runtime zu betreiben bedeutet zusätzliche Privilegien, Networking-Komplexität, Probleme bei der Dateisystem-Isolation — Dinge, die Sicherheitsteams prüfen müssen.
Enterprises müssen Compliance-Standards erfüllen (z. B. PCI-DSS, SOC2), die mittlerweile erwarten, dass Sie zeigen, wie Images gebaut, gescannt, isoliert und protokolliert werden.
Ein Kommentator merkte an:
"Sobald Sie geprüft werden und Docker nutzen, taucht das im Bericht auf... Sie müssen nachweisen... dass die Implementierung jedes einzelnen Images, das Sie verwenden, immun gegen Breakouts ist."
Das macht Container zu einem Risiko- und Audit-Thema, nicht nur zu einem Dev-Tool.
2. Legacy-Infrastruktur, restriktive Dev-Setups
Viele große Enterprises wickeln Dev-Arbeit über abgeschottete virtuelle Desktops (VDIs), gemeinsam genutzte Dev-Umgebungen oder ausgelagerte/remote arbeitende Dev-Teams ab. Diese Setups unterstützen oft weder verschachtelte Virtualisierung noch lokale Container-Runtimes. Aus dem Reddit-Thread:
"Eine der Beschränkungen war keine Virtualisierung innerhalb des virtuellen Desktops — also war Tooling wie Docker verboten."
Anders gesagt: Die Infrastruktur selbst erlaubt möglicherweise nicht die Art von Isolation oder privilegiertem Zugriff, die Docker erwartet.
3. Lizenzierung und Eigenheiten des Enterprise-Toolchains
Eine weitere Ebene ist Lizenzierung oder Unternehmensrichtlinie. Zum Beispiel eine Behauptung:
"Es geht nicht um Containerisierung, es geht darum, dass Dockers Lizenz die kostenlose Nutzung nur für Einzelpersonen und kleine Organisationen erlaubt."
Außerdem: Manche Artikel zeigen, dass den Open-Source- oder Community-Versionen von Docker Enterprise-taugliche Kontrollen (RBAC, Policy-Durchsetzung) fehlen können, was sie für große Organisationen weniger tragfähig macht.
Für Enterprises kann das "kostenlose" Modell also schnell wie "nicht unterstütztes Risiko" wirken — es sei denn, man zahlt, und zwar viel.
Was Entwickler stattdessen tun
Wenn ein Dev-Team also feststellt, dass Docker verboten ist, wie geht es damit um? Der Thread bietet interessante Workarounds und Praktiken:
A. Low-Level- oder alternative Runtimes
Viele verweisen auf Podman (und rootless Container) als sichere Alternative. Kommentare:
"Wechseln Sie einfach zu Podman, dann sind Sie fein raus."
"Podman gegenüber Docker für sicherheitskritische Sachen zu bevorzugen ist ziemlich vernünftig."
Weil Podman einen daemonlosen, rootless Modus bietet, sehen manche Enterprises es als weniger riskant an.
B. Gemeinsame Dev-Cluster statt lokaler Desktops
Ein weiterer Workaround: Wenn man Container nicht lokal ausführen kann, isolierte Umgebungen auf einem zentralen Cluster hochfahren. Ein Entwickler beschrieb:
"Das Muster, das ich dort funktionieren gesehen habe, ist, die Containerisierung auf einen gemeinsamen Cluster zu verschieben... jedem Dev oder Branch seinen eigenen Namespace zu geben... und Tests mit dieser Remote-Runtime statt mit einem lokalen Daemon sprechen zu lassen."
Das nimmt Container vom lokalen Rechner des Entwicklers (und dessen Sicherheitskontext) und verlagert sie in einen verwalteten, geprüften Raum.
C. Manuellere oder ältere Workflows
Manche Teams greifen einfach auf das zurück, was sie bereits kennen: gemeinsame Dev-Server, virtuelle Maschinen, lokale Installationen. Ein Kommentar:
"Wir haben eine einzige gemeinsam genutzte Dev-Umgebung... also hat sich das Team ständig gegenseitig das Zeug kaputtgemacht."
Für die Developer Experience ist das nicht ideal — aber angesichts der Unternehmensbeschränkungen manchmal der Weg des geringsten Widerstands.
Wie das ins größere Bild passt
Für jemanden wie Sie — der Backup-, Migrations- und Kubernetes-Workloads verwaltet — ist das Phänomen des Container-Verbots interessant. Hier ein paar breitere Blickwinkel:
Auch wenn Container bei vielen Greenfield-/Cloud-native-Shops Standard sind, hinken regulierte Enterprises (und besonders Legacy-Domänen) hinterher.
Wenn Container in solchen Umgebungen eingesetzt werden, liegt der starke Fokus auf Image-Herkunft, Scanning, Minimalismus (distroless/Alpine-Images), rootless-Modi. Sicherheit ist eher der Treiber als Entwickler-Agilität.
Bei Kubernetes-Nutzung ist der Wandel oft geradliniger: orchestrierte Cluster, streng kontrollierte Image-Registries, gehärtete Base-Images. Der Kampf dreht sich eher um lokales Entwickler-Tooling (Docker Desktop, lokale Container) als um die Produktions-Runtime.
Was das für Devs und Teams bedeutet
Wenn Sie sich in einer Umgebung wiederfinden, in der Docker verboten (oder eingeschränkt) ist, hier ein paar praktische Erkenntnisse:
Fragen Sie nach dem Warum: Liegt das Verbot an Lizenzierung, VDI-Beschränkungen, Audit-/Compliance-Richtlinien oder Legacy-Infrastruktur? Die Ursache zu verstehen macht es leichter, eine Lösung vorzuschlagen.
Schlagen Sie Abhilfen vor, nicht nur Forderungen: Wenn der Blocker Audit-Risiko ist, schlagen Sie Prozesse wie Image-Scanning, signierte Images, eine interne Registry vor. Wenn es die lokale Dev-Umgebung ist, schlagen Sie eine Remote-Container-Runtime oder Nur-CLI vor.
Erkunden Sie Alternativen (mit Vorsicht): Podman/rootless Container könnten akzeptabel sein. Oder schlagen Sie Container-Runtimes vor, die sich in den Enterprise-Toolchain integrieren.
Dokumentieren Sie Risiko/Nutzen: Wenn Sie sich entscheiden, Container zu umgehen, quantifizieren Sie, was Sie verlieren (Entwicklergeschwindigkeit, lokale Parität, TestContainers/localstack) gegenüber dem, was das Enterprise gewinnt (Auditierbarkeit, Isolation, vereinfachter Dev-Host).
Binden Sie Infrastruktur-Teams früh ein: Wenn Ihr Dev-Team für Dinge wie lokale Testumgebungen (z. B. für Kubernetes-Workloads) auf Container angewiesen ist, holen Sie Infra-/Sicherheitsteams früh ins Gespräch, damit der lokale Workflow angepasst statt schlicht verboten werden kann.
Ein Vorbehalt: Es ist nicht immer "Docker für immer verboten"
Selbst bei Teams, die "kein Docker" behaupten, finden Sie Ausnahmen: In der Produktion laufen möglicherweise weiterhin Container (auf Kubernetes oder orchestrierten Clustern), aber lokales Dev-Tooling (Docker Desktop, verschachtelte Virtualisierung) ist eingeschränkt. Wie es ein Kommentator formulierte:
"Hier geht es um Docker im Dev-Prozess, nicht um den Einsatz in Prod."
Die absolute "Keine Container"-Haltung ist also selten. Häufiger ist es "keine lokalen, unverwalteten Container-Runtimes".
Fazit
Für viele Enterprises liegt das Problem nicht darin, dass Container schlecht sind — sondern dass unverwaltetes, lokales Container-Tooling (besonders auf Desktops/VDIs) zusätzliche Schichten von Risiko, Komplexität und Audit-Exposition mit sich bringt. Für Entwickler bedeutet das: Der beste Weg ist, die Beschränkungen zu verstehen, an sicheren Alternativen mitzuwirken (Remote-Runtimes, rootless Container, gemeinsame Cluster) und den eigenen Workflow weiterzuentwickeln, statt das Verbot frontal zu bekämpfen.