Sichern von Windows-Containern

Gilt für: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

Container verleihen ihrer reduzierten Imagegröße die Tatsache, dass sie sich auf den Host verlassen können, um eingeschränkten Zugriff auf verschiedene Ressourcen zu ermöglichen. Wenn der Container weiß, dass der Host die funktionalität bereitstellen kann, die zum Ausführen einer bestimmten Gruppe von Aktionen erforderlich ist, muss der Container die relevante Software nicht in das Basisimage aufnehmen. Das Ausmaß der Ressourcenfreigabe kann sich jedoch erheblich auf die Leistung und Sicherheit des Containers auswirken. Wenn zu viele Ressourcen freigegeben werden, kann die Anwendung genauso gut wie ein Prozess auf dem Host ausgeführt werden. Wenn die Ressourcen zu wenig freigegeben werden, wird der Container von einem virtuellen Computer nicht mehr unterschieden. Beide Konfigurationen gelten für viele Szenarien, aber die meisten Benutzer, die Container verwenden, entscheiden sich in der Regel für etwas in der Mitte.

Die Sicherheit eines Windows-Containers leitet sich aus dem Grad der gemeinsamen Verwendung ab, die mit seinem Host stattfindet. Die Sicherheitsgrenze eines Containers besteht aus den Isolationsmechanismen, die den Container vom Host trennen. Am wichtigsten ist, dass diese Isolationsmechanismen definieren, welche Prozesse im Container mit dem Host interagieren können. Wenn der Entwurf eines Containers die Interaktion mit dem Host durch einen Prozess mit erhöhten Rechten (Administratoren) ermöglicht, wird dieser Container von Microsoft nicht als robuste Sicherheitsgrenze betrachtet.

Windows Server-Container im Vergleich zu Linux-Containern

Die unter Prozessisolation laufenden Windows Server-Container und Linux-Container weisen ähnliche Isolationsgrade auf. Für beide Containertypen muss der Entwickler alle Angriffe annehmen, die über einen erhöhten Prozess auf dem Host ausgeführt werden können, auch über einen Prozess mit erhöhten Rechten im Container ausgeführt werden können. Beide funktionieren über die primitiven Funktionen, die von ihren jeweiligen Hostkernen angeboten werden. Die Containerimages werden mit Binärdateien für den Benutzermodus erstellt, die die vom Hostkernel bereitgestellten APIs verwenden. Der Hostkernel bietet die gleichen Ressourcenisolations- und Verwaltungsfunktionen für jeden Container, der im Benutzerbereich ausgeführt wird. Wenn der Kernel kompromittiert ist, gilt das auch für jeden Container, der diesen Kernel gemeinsam verwendet.

Das grundlegende Design von Linux- und Windows-Servercontainern kompromittiert die Sicherheit zugunsten von Flexibilität. Windows Server- und Linux-Container basieren auf den primitiven Komponenten, die vom Betriebssystem bereitgestellt werden. Dies bietet die Flexibilität beim Freigeben von Ressourcen und Namespaces zwischen Containern, fügt aber zusätzliche Komplexität hinzu, die die Tür zur Ausbeutung öffnet. Ganz allgemein gesagt betrachten wir den Kernel nicht als ausreichende Sicherheitsgrenze für gefährdete Workloads mit mehreren Mandanten.

Kernelisolation mit Hypervisor-isolierten Containern

Hypervisor-isolierte Container bieten einen höheren Grad an Isolation als prozessisolieren Windows Server- oder Linux-Container und gelten als robuste Sicherheitsgrenze. Hypervisor-isolierte Container bestehen aus einem Windows Server-Container, der in eine leichtgewichtige VM eingeschlossen ist, und laufen dann parallel zum Hostbetriebssystem über den Hypervisor von Microsoft. Der Hypervisor stellt eine Isolation auf Hardwareebene bereit, die eine äußerst robuste Sicherheitsgrenze zwischen dem Host und anderen Containern enthält. Selbst wenn ein Exploit den Windows Server-Container umgehen würde, würde er in der hypervisorisolierten VM enthalten sein.

Weder Windows Server-Container noch Linux-Container bieten, was Microsoft als stabile Sicherheitsgrenze betrachtet und sollte nicht in feindlichen Szenarien mit mehreren Mandanten verwendet werden. Ein Container muss auf einen dedizierten virtuellen Computer beschränkt sein, um zu verhindern, dass ein nicht autorisierter Containerprozess mit dem Host oder anderen Mandanten interagiert. Die Hypervisorisolation ermöglicht diesen Grad der Trennung und bietet gleichzeitig mehrere Leistungssteigerungen gegenüber herkömmlichen VMs. Daher wird dringend empfohlen, in möglicherweise gefährdeten Szenarien mit mehreren Mandanten durch Hypervisoren isolierte Container als Container der Wahl zu verwenden.

Kriterien für die Wartung der Containersicherheit

Microsoft verpflichtet sich, alle Exploits und Escapes zu patchen, die die etablierten Isolationsgrenzen eines beliebigen Windows-Containertyps unterbrechen. Allerdings werden nur Exploits, die eine Sicherheitsgrenze unterbrechen, über den MsRC-Prozess (Microsoft Security Response Center) gewartet. Nur Hypervisor-isolierte Container stellen eine Sicherheitsgrenze bereit, während prozessisolierte Container dies nicht tun. Die einzige Möglichkeit zum Generieren eines Fehlers für einen prozessisolten Container escape ist, wenn ein Nicht-Administratorprozess Zugriff auf den Host erhalten kann. Wenn ein Exploit einen Administratorprozess verwendet, um dem Container zu entkommen, hält Microsoft ihn für einen nicht sicherheitsrelevanten Fehler und patcht ihn gemäß dem normalen Wartungsvorgang. Wenn ein Exploit einen Nicht-Administratorprozess verwendet, um eine Aktion auszuführen, die eine Sicherheitsgrenze verletzt, wird es von Microsoft anhand der festgelegten Sicherheitswartungskriterienuntersucht.

Wann ist eine mehrmandantenfähige Workload gefährdet?

Umgebungen mit mehreren Mandanten liegen vor, wenn mehrere Workloads in einer gemeinsam genutzten Infrastruktur und auf gemeinsam genutzten Ressourcen ausgeführt werden. Wenn eine oder mehrere Workloads, die auf einer Infrastruktur ausgeführt werden, nicht vertrauenswürdig sein können, wird die Mehrinstanzenumgebung als feindlich angesehen. Sowohl Windows Server- als auch Linux-Container teilen den Kernel des Hosts, sodass alle Exploits, die auf einem einzelnen Container ausgeführt werden, Auswirkungen auf alle anderen Arbeitslasten haben können, die auf der gemeinsam genutzten Infrastruktur laufen.

Sie können Schritte ausführen, um die Wahrscheinlichheit zu verringern, dass ein Exploit auftritt, z. B. mithilfe von Pod-Sicherheitsrichtlinien, AppArmor und rollenbasierter Zugriffssteuerung (RBAC), aber sie bieten keinen garantierten Schutz vor einem Angreifer. Wir empfehlen, unsere bewährten Methoden für die Clusterisolation für jedes Multi-Tenant-Szenario zu befolgen.

Wann ContainerAdmin- und ContainerUser-Benutzerkonten verwendet werden

Windows Server-Container bieten zwei Standardbenutzerkonten, ContainerUser und ContainerAdministrator, jeweils mit ihrem eigenen spezifischen Zweck. Mit dem ContainerAdministrator-Konto können Sie den Container für administrative Zwecke verwenden: Installieren von Diensten und Software (z. B. Aktivieren von IIS in einem Container), Vornehmen von Konfigurationsänderungen und Erstellen neuer Konten. Diese Aufgaben sind für eine Reihe von IT-Szenarien wichtig, die in benutzerdefinierten lokalen Bereitstellungsumgebungen ausgeführt werden können.

Das ContainerUser-Konto ist für alle anderen Szenarien vorhanden, in denen Administratorrechte in Windows nicht benötigt werden. Wenn die benutzende Person in Kubernetes beispielsweise ContainerAdministrator ist und Hostvolumes in den Pod eingebunden werden dürfen, kann die benutzende Person den SSH-Ordner einbinden und einen öffentlichen Schlüssel hinzufügen. Als ContainerUser wäre dieses Beispiel nicht möglich. Es handelt sich um ein eingeschränktes Benutzerkonto, das ausschließlich für Anwendungen entwickelt wurde, die nicht mit dem Host interagieren müssen. Es wird dringend empfohlen, dass beim Bereitstellen eines Windows-Servercontainers in jeder mehrinstanzenfähigen Umgebung Ihre Anwendung über das ContainerUser-Konto läuft. In einer Umgebung mit mehreren Mandanten ist es immer am besten, das Prinzip der geringstmöglichen Berechtigungen zu befolgen, denn wenn ein Angreifer die Sicherheit Ihrer Workload beschädigt, ist so die Wahrscheinlichkeit geringer, dass die gemeinsam genutzte Ressource und die benachbarten Workloads ebenfalls beeinträchtigt werden. Das Ausführen von Containern mit dem ContainerUser-Konto verringert die Wahrscheinlichkeit stark, dass die Umgebung als Ganzes kompromittiert wird. Dies bietet jedoch weiterhin keine robuste Sicherheitsgrenze, daher sollten Sie Hypervisor-isolierte Container verwenden, wenn Sicherheit wichtig ist.

Um das Benutzerkonto zu ändern, können Sie die USER-Anweisung in Ihrer Dockerfile-Datei verwenden:

USER ContainerUser

Alternativ können Sie einen neuen Benutzer erstellen:

RUN net user username ‘<password>’ /ADD
USER username

Windows-Dienste

Mit Microsoft Windows-Diensten, früher als NT-Dienste bezeichnet, können Sie ausführbare Anwendungen mit langer Ausführung erstellen, die in ihren eigenen Windows-Sitzungen ausgeführt werden. Diese Dienste können automatisch gestartet werden, wenn das Betriebssystem gestartet wird, angehalten und neu gestartet werden und keine Benutzeroberfläche anzeigen. Sie können dienste auch im Sicherheitskontext eines bestimmten Benutzerkontos ausführen, das sich von dem angemeldeten Benutzer oder dem Standardcomputerkonto unterscheidet.

Beim Containerisieren und Sichern einer Arbeitsauslastung, die als Windows-Dienst ausgeführt wird, sind einige zusätzliche Überlegungen zu beachten. Erstens wird die ENTRYPOINT des Containers nicht die Workload sein, da der Dienst als Hintergrundprozess ausgeführt wird, in der Regel ist die ENTRYPOINT ein Tool wie Dienstmonitor) oder Protokollmonitor). Zweitens wird das Sicherheitskonto, unter dem die Workload arbeitet, vom Dienst konfiguriert, nicht durch die USER-Direktive in der Dockerfile-Datei. Sie können überprüfen, unter welchem Konto der Dienst ausgeführt wird, indem Sie Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartNameausführen.

Wenn Sie z. B. eine IIS-Webanwendung mit dem ASP.NET (Microsoft-Artefaktregistrierung)-Image hosten, lautet der ENTRYPOINT des Containers "C:\\ServiceMonitor.exe", "w3svc". Dieses Tool kann verwendet werden, um den IIS-Dienst zu konfigurieren und dann den Dienst zu überwachen, um sicherzustellen, dass er ausgeführt und beendet wird, wodurch der Container gestoppt wird, wenn der Dienst aus irgendeinem Grund beendet wird. Standardmäßig wird der IIS-Dienst und damit die Webanwendung unter einem Konto mit geringen Berechtigungen im Container ausgeführt, das Dienstüberwachungstool erfordert jedoch Administratorrechte zum Konfigurieren und Überwachen des Diensts.