Säkerhet, lagring och nätverk med Windows-containrar
Contoso har bett dig som Windows Server-administratör att utvärdera säkerhets-, lagrings- och nätverksbehoven för Windows-containrar. Du är särskilt intresserad av att förstå hur dessa behov skiljer sig mellan containrar och virtuella datorer i Windows Server.
Säkerhet för Windows-containrar
Windows-containrar bygger på samma bas som Windows-instanser som körs på fysiska eller virtuella datorer. Vissa säkerhetsaspekter hanteras dock på olika sätt eller är specifika för Windows-containrar:
Delade komponenter. Windows-containrar delar några av värdens komponenter i säkerhetssyfte. Detta omfattar Windows-brandväggen, Windows Defender (Antivirus) och andra begränsningar för resursåtkomst. Du behöver inte konfigurera dessa komponenter på containern direkt eftersom containervärden gör de nödvändiga justeringarna baserat på din containerarbetsbelastning. Om containern till exempel gör en webbbegäran vidarebefordrar containervärden nödvändig trafik via brandväggen så att containern kan komma åt webben.
Isoleringsläge. Windows-containrar kan distribueras i process- eller Hyper-V-isoleringsläge, med Hyper-V som ger den säkraste isoleringen. I processisolering delar containern sin kernel, sitt filsystem och sitt register med värden, vilket gör att en upphöjd process (administratör) kan interagera med containerprocesserna och -tjänsterna. Det är viktigt att välja rätt isoleringsläge för ditt program för att säkerställa rätt säkerhetsläge.
Windows-uppdateringar. Eftersom servicestacken inte finns i Windows-containrar tar Windows-containrar inte emot uppdateringar som allmänna Windows-instanser. I stället måste du återskapa Windows-containrar med den senaste tillgängliga bascontaineravbildningen. Kunder kan använda Azure-pipelines för detta ändamål. Microsoft uppdaterar bascontaineravbildningarna för alla sina officiella avbildningar varje månad efter Patch Tuesday-kadensen.
Containeranvändarkonto. Som standard körs program i Windows-containrar med förhöjd behörighet under Användarkontot ContainerAdmin. Det här är användbart för att installera och konfigurera nödvändiga komponenter i containeravbildningen. Du bör dock överväga att ändra användarkontot till ContainerUser när du kör ett program som inte kräver förhöjd behörighet. För specifika scenarier kan du också skapa ett nytt konto med rätt behörighet.
Avbildning och körningsgenomsökning. Containrar kräver att avbildningar på lagringsplatser och containrar är säkra. Microsoft rekommenderar att du använder Microsoft Defender för containrar för avbildningsgenomsökning och körningsgenomsökning. Defender for Containers har stöd för Windows-containrar för sårbarhetsbedömning med registergenomsökning och körningsskydd med hotidentifiering.
Mer information om säkerheten för Windows-containrar finns i Skydda Windows-containrar.
Beständig lagring för Windows-containrar
Windows-containrar använder som standard tillfällig lagring. Alla container-I/O sker i ett "scratch space". Ett ledigt utrymme är ett tillfälligt lagringsutrymme som tillhandahålls till containern för ändringar i filsystemet. Varje container får sin egen repa. Filskapande och filskrivningar samlas in i scratch-utrymmet och kommer inte undan till värden. När en containerinstans tas bort kastas alla ändringar som har inträffat i det tillfälliga utrymmet bort. När en ny containerinstans startas tillhandahålls ett nytt ledigt utrymme för instansen.
Du kan ha fall där det är viktigt att en app kan spara data i en container, eller om du vill visa filer i en container som inte ingick i containerversionen. Därför kan beständiga lagringar tillhandahållas till Windows-containrar.
Beständiga lagringar kan tillhandahållas till Windows-containrar antingen via Docker-motorn eller containerorkestratorn. I utvecklings-/testmiljöer ger Docker-motorn ett snabbt och enkelt sätt att tilldela lokal lagring till Windows-containrar med bindningsmonteringar eller namngivna volymer. Med bindningsmonteringar kan en container dela en katalog med värden. Det här är användbart om du vill att en plats ska lagra filer på den lokala datorn som är tillgängliga om du startar om en container eller vill dela den med flera containrar. Om du vill att containern ska köras på flera datorer med åtkomst till samma filer ska en namngiven volym eller SMB-montering användas i stället.
För produktionsmiljöer kan containerorkestreraren tillhandahålla beständiga lagringsalternativ i företagsklass. Kubernetes tillhandahåller till exempel inbyggda beständiga volymer som kan användas för att tillhandahålla beständig lagring för flera containrar som körs på flera värdar. Dessutom tillhandahåller Kubernetes även plugin-program från tredje part som ska användas för att mappa volymer på molnlagring, till exempel Azure Storage.
Mer information om beständig lagring för Windows-containrar finns i Översikt över Container Storage.
Nätverk för Windows-containrar
Windows-containrar fungerar på samma sätt som virtuella datorer när det gäller nätverk. Varje container har ett virtuellt nätverkskort (vNIC) som är anslutet till en virtuell Hyper-V-växel (vSwitch). Windows stöder fem olika nätverksdrivrutiner eller lägen som kan skapas via Docker: nat, overlay, transparent, l2bridge och l2tunnel. Beroende på din fysiska nätverksinfrastruktur och krav på nätverk mellan en och flera värdar bör du välja den nätverksdrivrutin som bäst passar dina behov.
| Docker Windows-nätverksdrivrutin | Vanliga användningsområden | Container-till-container (enskild nod) | Container-till-extern (enskild nod + flera noder) | Container-till-container (flera noder) |
|---|---|---|---|---|
| NAT (standard) | Bra för utvecklare | Samma undernät: Bryggd anslutning via virtuell Hyper-V-växel Korsundernät: Stöds inte (endast ett internt NAT-prefix) |
Dirigerat via hantering av virtuellt nätverkskort (bundet till WinNAT) | Stöds inte direkt: kräver att portar exponeras via värden |
| Transparent | Bra för utvecklare eller små distributioner | Samma undernät: Bryggd anslutning via virtuell Hyper-V-växel Korsundernät: Dirigeras via containervärden |
Dirigeras via containervärd med direkt åtkomst till (fysiskt) nätverkskort | Dirigeras via containervärd med direkt åtkomst till (fysiskt) nätverkskort |
| Överlägg | Bra för flera noder; krävs för Docker Swarm, tillgängligt i Kubernetes | Samma undernät: Bryggd anslutning via virtuell Hyper-V-växel Korsundernät: Nätverkstrafik kapslas in och dirigeras via mgmt vNIC |
Stöds inte direkt – kräver den andra containerslutpunkten som är ansluten till NAT-nätverket på Windows Server 2016 eller VFP NAT-regeln i Windows Server 2019. | Samma/korsande undernät: Nätverkstrafiken kapslas in med VXLAN och dirigeras via Mgmt vNIC |
| L2Bridge | Används för Kubernetes och Microsoft SDN | Samma undernät: Bryggd anslutning via virtuell Hyper-V-växel Korsundernät: Mac-containeradressen skrivs om vid ingress och utgående och dirigerad |
Mac-containeradressen skrivs om vid ingress och utgående | Samma undernät: Bryggd anslutning Korsundernät: dirigeras via Mgmt vNIC på WSv1809 och senare |
| L2Tunnel | Endast Azure | Samma/korsande undernät: Hårfäst på den fysiska värdens virtuella Hyper-V-växel till den plats där principen tillämpas | Trafiken måste gå via en virtuell Azure-nätverksgateway | Samma/korsande undernät: Hårfäst på den fysiska värdens virtuella Hyper-V-växel till den plats där principen tillämpas |
Utöver Docker-alternativen ovan tillhandahåller Kubernetes olika CNI-plugin-program (Container Network Interface). Dessa CNI implementerar olika lägen för nätverkskonfiguration, nätverksprinciper osv.
Mer information om nätverk för Windows-containrar finns i Nätverk för Windows-containrar.