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, nur eben nicht überall. Immer wieder berichten Entwickler bei großen regulierten Organisationen (Banken, Versicherer, große 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. Was ist da also 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, aus Sicht eines reifen Enterprise sind sie eine weitere Angriffsfläche. Eine Container-Runtime zu betreiben bedeutet zusätzliche Privilegien, Networking-Komplexität und Probleme bei der Dateisystem-Isolation, und all das müssen Sicherheitsteams prüfen. Dazu kommt, dass Enterprises Compliance-Standards erfüllen müssen (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."

Damit werden Container zu einem Risiko- und Audit-Thema und sind längst nicht mehr nur ein 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 und 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. Eine Behauptung aus dem Thread:

"Es geht nicht um Containerisierung, es geht darum, dass Dockers Lizenz die kostenlose Nutzung nur für Einzelpersonen und kleine Organisationen erlaubt."

Manche Artikel zeigen außerdem, 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 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:

"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, fährt man isolierte Umgebungen auf einem zentralen Cluster hoch. Ein Entwickler beschrieb es so:

"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, angesichts der Unternehmensbeschränkungen aber manchmal der Weg des geringsten Widerstands.

Wie das ins größere Bild passt

Wer Backup-, Migrations- und Kubernetes-Workloads verwaltet, findet das Phänomen des Container-Verbots aus mehreren Gründen interessant.

Auch wenn Container bei vielen Greenfield- und 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- oder Alpine-Images) und rootless-Modi. Der Treiber ist dann eher Sicherheit 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, helfen ein paar praktische Erkenntnisse.

Fragen Sie zuerst nach dem Warum. Liegt das Verbot an Lizenzierung, VDI-Beschränkungen, Audit- und Compliance-Richtlinien oder Legacy-Infrastruktur? Die Ursache zu verstehen macht es leichter, eine Lösung vorzuschlagen.

Schlagen Sie dann Abhilfen vor und nicht nur Forderungen. Wenn der Blocker Audit-Risiko ist, schlagen Sie Prozesse wie Image-Scanning, signierte Images und eine interne Registry vor. Wenn es die lokale Dev-Umgebung ist, schlagen Sie eine Remote-Container-Runtime oder einen Nur-CLI-Weg vor.

Erkunden Sie Alternativen mit Vorsicht. Podman und rootless Container könnten akzeptabel sein, oder Sie schlagen Container-Runtimes vor, die sich in den Enterprise-Toolchain integrieren.

Dokumentieren Sie Risiko und Nutzen. Wenn Sie sich entscheiden, Container zu umgehen, quantifizieren Sie, was Sie verlieren (Entwicklergeschwindigkeit, lokale Parität, TestContainers oder localstack) gegenüber dem, was das Enterprise gewinnt (Auditierbarkeit, Isolation, vereinfachter Dev-Host).

Und 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- und 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 wie Docker Desktop oder 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

Viele Enterprises haben mit Containern an sich kein Problem. Sie stören sich an unverwaltetem, lokalem Container-Tooling, besonders auf Desktops und VDIs, weil es zusätzliche Schichten von Risiko, Komplexität und Audit-Exposition mitbringt. Für Entwickler heißt das: Die Beschränkungen verstehen, an sicheren Alternativen mitwirken (Remote-Runtimes, rootless Container, gemeinsame Cluster) und den eigenen Workflow weiterentwickeln, statt das Verbot frontal zu bekämpfen.