Windows-containers beveiligen

Van toepassing op: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

Containers hebben hun kleinere beeldgrootte te danken aan het feit dat ze op de host kunnen vertrouwen om beperkte toegang tot verschillende resources te bieden. Als de container weet dat de host de functionaliteit kan bieden die nodig is om een specifieke set acties uit te voeren, hoeft de container de relevante software niet op te nemen in de basisinstallatiekopie. Het delen van resources kan echter een aanzienlijke invloed hebben op zowel de prestaties als de beveiliging van de container. Als er te veel resources worden gedeeld, kan de toepassing net zo goed worden uitgevoerd als een proces op de host. Als de resources te weinig worden gedeeld, wordt de container niet meer te onderscheiden van een VIRTUELE machine. Beide configuraties zijn van toepassing op veel scenario's, maar de meeste mensen die containers gebruiken, kiezen meestal voor iets in het midden.

De beveiliging van een Windows-container is afgeleid van de mate van delen die plaatsvindt met de host. De beveiligingsgrens van een container wordt gevormd door de isolatiemechanismen die de container scheiden van de host. Het belangrijkste is dat deze isolatiemechanismen definiëren welke processen in de container kunnen communiceren met de host. Als het ontwerp van een container toestaat dat een proces met verhoogde bevoegdheid (beheerder) met de host kan communiceren, is deze container niet van mening dat deze container een robuuste beveiligingsgrens heeft.

Windows Server-containers versus Linux-containers

Proces-geïsoleerde Windows Server-containers en Linux-containers delen vergelijkbare isolatiegraden. Voor beide containertypen moet de ontwikkelaar ervan uitgaan dat elke aanval die kan worden uitgevoerd via een verhoogd proces op de host, ook kan worden uitgevoerd via een verhoogd proces in de container. Beide werken via de primitieve mogelijkheden die worden aangeboden door hun respectieve host kernels. De containerafbeeldingen zijn opgebouwd uit binaire bestanden in de gebruikersmodus die gebruikmaken van de API's die door de hostkernel worden geleverd. De hostkernel biedt dezelfde resourceisolatie- en beheermogelijkheden voor elke container die in de gebruikersruimte wordt uitgevoerd. Als de kernel is gecompromitteerd, dan geldt dat ook voor elke container die de kernel deelt.

Het fundamentele ontwerp van Linux- en Windows-servercontainers ruilt beveiliging in voor flexibiliteit. Windows Server- en Linux-containers zijn gebouwd op basis van de primitieve onderdelen van het besturingssysteem. Dit biedt de flexibiliteit voor het delen van resources en naamruimten tussen containers, maar het voegt extra complexiteit toe waarmee de deur voor exploitatie wordt geopend. Algemeen gezegd, we de kernel niet beschouwen als een voldoende beveiligingsgrens voor vijandige workloads met meerdere tenants.

Kernelisolatie met geïsoleerde hypervisorcontainers

Hypervisor-geïsoleerde containers bieden een hogere mate van isolatie dan proces-geïsoleerde Windows Server- of Linux-containers en worden beschouwd als robuuste beveiligingsgrens. Hypervisor-geïsoleerde containers bestaan uit een Windows Server-container die is verpakt in een ultralichte VM en worden vervolgens uitgevoerd naast het hostbesturingssysteem via de hypervisor van Microsoft. De hypervisor biedt isolatie op hardwareniveau met een zeer robuuste beveiligingsgrens tussen de host en andere containers. Zelfs als een aanval zou ontsnappen aan de Windows Server-container, zou deze zich in de geïsoleerde hypervisor-VM bevinden.

Windows Server-containers of Linux-containers bieden niet wat Microsoft beschouwt als een robuuste beveiligingsgrens en mag niet worden gebruikt in vijandige scenario's met meerdere tenants. Een container moet worden beperkt tot een specifieke VM om te voorkomen dat een kwaadaardig containerproces communiceert met de host of andere tenants. Hypervisorisolatie maakt deze mate van scheiding mogelijk en biedt ook verschillende prestatieverbeteringen ten opzichte van traditionele VM's. Daarom wordt sterk aanbevolen in vijandige multi-tenant scenario's de voorkeur te geven aan hypervisor-geïsoleerde containers.

Servicecriteria voor containerbeveiliging

Microsoft streeft ernaar om alle aanvallen en escapes te patchen die de vastgestelde isolatiegrens van elk Windows-containertype verbreken. Alleen aanvallen die een beveiligingsgrens verbreken, worden echter verwerkt via het MSRC-proces (Microsoft Security Response Center). Alleen hypervisor-geïsoleerde containers bieden een beveiligingsgrens en proces-geïsoleerde containers niet. De enige manier om een fout te genereren voor een proces-geïsoleerde container escape is als een niet-beheerproces toegang tot de host kan krijgen. Als een misbruik gebruikmaakt van een beheerproces om aan de container te ontsnappen, beschouwt Microsoft dit als een niet-beveiligingsfout en wordt deze gepatcht volgens het normale onderhoudsproces. Als een misbruik gebruikmaakt van een niet-beheerdersproces om een actie uit te voeren die een beveiligingsgrens schendt, onderzoekt Microsoft dit volgens de vastgestelde criteria voor beveiligingsonderhoud.

Wat maakt een workload met meerdere gebruikers problematisch?

Omgevingen met meerdere tenants bestaan wanneer meerdere workloads worden uitgevoerd op een gedeelde infrastructuur en resources. Als een of meer workloads die worden uitgevoerd op een infrastructuur niet kunnen worden vertrouwd, wordt de multi-tenant-omgeving als vijandig beschouwd. Zowel Windows Server- als Linux-containers delen de hostkernel, dus elke exploit die wordt uitgevoerd op één container kan van invloed zijn op alle andere workloads die worden uitgevoerd op de gedeelde infrastructuur.

U kunt stappen ondernemen om de kans te verminderen dat een aanval plaatsvindt, bijvoorbeeld door gebruik te maken van beveiligingsbeleid voor pods, AppArmor en op rollen gebaseerd toegangsbeheer (RBAC), maar ze bieden geen gegarandeerde bescherming tegen een aanvaller. We raden u aan onze best practices voor clusterisolatie te volgen voor elk multitenant-scenario.

Wanneer moet u gebruikersaccounts ContainerAdmin en ContainerUser gebruiken

Windows Server-containers bieden twee standaardgebruikersaccounts, ContainerUser en ContainerAdministrator, elk met hun eigen specifieke doel. Met het ContainerAdministrator-account kunt u de container gebruiken voor beheerdoeleinden: services en software installeren (zoals IIS inschakelen binnen een container), configuratiewijzigingen aanbrengen en nieuwe accounts maken. Deze taken zijn belangrijk voor een aantal IT-scenario's die kunnen worden uitgevoerd in aangepaste, on-premises implementatieomgevingen.

Het ContainerUser-account bestaat voor alle andere scenario's waarbij beheerdersbevoegdheden in Windows niet nodig zijn. Als de gebruiker bijvoorbeeld ContainerAdministrator is in Kubernetes en hostvolumes mag worden gekoppeld aan de pod, kan de gebruiker de map .ssh koppelen en een openbare sleutel toevoegen. Als ContainerUser zou dit voorbeeld niet mogelijk zijn. Het is een beperkt gebruikersaccount dat uitsluitend is ontworpen voor toepassingen die niet hoeven te communiceren met de host. We raden u sterk aan om, bij het implementeren van een Windows-servercontainer in een multi-tenant omgeving, uw toepassing via het ContainerUser-account te laten draaien. In een omgeving met meerdere tenants is het altijd het beste om het principe van minimale bevoegdheden te volgen, omdat een aanvaller uw workload kan compromitteren, en zo is de kans kleiner dat de gedeelde hulpbron en aangrenzende workloads ook gevolgen ondervinden. Het uitvoeren van containers met het ContainerUser-account vermindert de kans aanzienlijk dat de omgeving als geheel wordt aangetast. Dit biedt echter nog steeds geen robuuste beveiligingsgrens, dus wanneer beveiliging een probleem is, moet u hypervisor-geïsoleerde containers gebruiken.

Als u het gebruikersaccount wilt wijzigen, kunt u de USER-opdracht in uw dockerfile gebruiken.

USER ContainerUser

U kunt ook een nieuwe gebruiker maken:

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

Windows-services

Met Microsoft Windows-services, voorheen bekend als NT-services, kunt u langlopende uitvoerbare toepassingen maken die worden uitgevoerd in hun eigen Windows-sessies. Deze services kunnen automatisch worden gestart wanneer het besturingssysteem wordt gestart, kunnen worden onderbroken en opnieuw worden opgestart en geen gebruikersinterface weergeven. U kunt ook services uitvoeren in de beveiligingscontext van een specifiek gebruikersaccount dat verschilt van de aangemelde gebruiker of het standaardcomputeraccount.

Bij het containeriseren en beveiligen van een workload die wordt uitgevoerd als een Windows-service, moet u rekening houden met enkele aanvullende overwegingen. Ten eerste is ENTRYPOINT van de container niet de workload omdat de service wordt uitgevoerd als achtergrondproces, meestal is ENTRYPOINT een hulpprogramma zoals servicemonitor) of logboekmonitor). Ten tweede wordt het beveiligingsaccount waarvoor de workload werkt, geconfigureerd door de service niet door de GEBRUIKERS-instructie in het dockerfile. U kunt controleren onder welk account de service wordt uitgevoerd door Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartNameuit te voeren.

Wanneer u bijvoorbeeld een IIS-webtoepassing host en de ASP.NET (Microsoft Artifact Registry) afbeelding gebruikt, wordt de ENTRYPOINT van de container "C:\\ServiceMonitor.exe", "w3svc". Dit hulpprogramma kan worden gebruikt om de IIS-service te configureren en controleert vervolgens de service om ervoor te zorgen dat deze actief blijft en wordt afgesloten, waardoor de container wordt gestopt als de service om welke reden dan ook stopt. De IIS-service en dus de webtoepassing worden uitgevoerd onder een account met lage bevoegdheden in de container, maar het hulpprogramma voor servicecontrole vereist beheerdersbevoegdheden voor het configureren en bewaken van de service.