Container su Windows Server

Container su Windows Server: il modello

I Windows container impacchettano un’applicazione con le sue dipendenze in un’unità isolata che condivide il kernel dell’host, a differenza di una VM che virtualizza hardware e sistema operativo completi. Su Windows Server 2022/2025 il runtime tipico è containerd (o Docker/Mirantis nei deployment legacy), orchestrabile con Kubernetes. Il punto d’esame non è “come si installa”, ma capire il grado di isolamento e la compatibilità fra host e immagine: da lì derivano le scelte di sicurezza e di supportabilità.

Isolation modes: process vs Hyper-V

Windows offre due isolation modes, selezionabili a runtime e non in fase di build.

Con process isolation i container condividono il kernel dell’host: ogni container vede processi separati ma lo stesso kernel. È la modalità più leggera (avvio rapido, overhead minore, densità alta) ed è il default su Windows Server. Il vincolo è la compatibilità di versione: la build del base image deve corrispondere a quella dell’host, perché condividono le stesse componenti kernel.

Con Hyper-V isolation ogni container gira in una utility VM minimale con un proprio kernel dedicato. Il confine di sicurezza è quello di una macchina virtuale, quindi è la scelta per workload non fidati o multi-tenant. Inoltre, disaccoppiando il kernel, consente di eseguire immagini con versione diversa da quella dell’host. Il prezzo è più overhead di memoria e un avvio più lento.

Regola pratica: process isolation per workload fidati e omogenei dove contano densità e performance; Hyper-V isolation quando serve un confine forte o quando l’immagine non è allineata all’host.

Base images e compatibilità

Microsoft distribuisce alcune base images ufficiali con superfici API diverse:

• Nano Server: minima, per app moderne (.NET, cloud-native); footprint ridotto ma API limitate.
• Server Core: superficie più ampia (es. .NET Framework tradizionale, molti componenti Windows); più pesante.
• Windows: immagine più completa, per app che richiedono API non presenti nelle altre.

La versione dell’immagine (il tag legato alla release dell’OS) governa la compatibilità: con process isolation la corrispondenza di build host/immagine è stringente; con Hyper-V isolation puoi eseguire immagini più vecchie su un host più recente. Immagini più piccole riducono anche la superficie d’attacco e i tempi di pull.

Registry e sicurezza dei container

Le immagini vivono in un container registry. Le base images ufficiali provengono dal Microsoft Container Registry (MCR); per le immagini proprietarie si usa tipicamente un registry privato come Azure Container Registry (ACR), che offre RBAC via Entra ID, private endpoint per isolare il traffico dalla rete pubblica, geo-replication e scansione delle vulnerabilità (integrabile con Microsoft Defender for Containers).

Sul fronte security le priorità sono: preferire identità (managed identity o service principal) alle credenziali statiche, tenendo disabilitato l’admin account del registry; scansionare le immagini e ricostruirle spesso per assorbire le patch (un container non si “aggiorna” a caldo: si ridistribuisce da un’immagine aggiornata); eseguire i processi con il minimo privilegio (ContainerUser invece di ContainerAdministrator quando non serve); e ricordare che con process isolation il kernel è condiviso, quindi non offre un confine di sicurezza equivalente a una VM.

Trappole tipiche d’esame

• Workload multi-tenant o non fidato → Hyper-V isolation: il kernel condiviso di process isolation non è un confine di sicurezza adeguato; serve la utility VM.
• Immagine con versione diversa dall’host → Hyper-V isolation: process isolation richiede build allineate; Hyper-V isolation disaccoppia il kernel e ammette il mismatch.
• Massima densità e avvio rapido su host fidato → process isolation: è più leggera; scegliere Hyper-V “per sicurezza” a prescindere è overengineering che penalizza le performance.
• Isolare il pull delle immagini dalla rete pubblica → private endpoint su ACR: l’RBAC da solo non basta, serve il private endpoint per chiudere l’accesso pubblico.
• Ridurre la superficie d’attacco dell’immagine → Nano Server (se le API bastano): Server Core solo quando servono componenti come .NET Framework.
• Patch di sicurezza su un container in esecuzione → ricostruire e ridistribuire l’immagine: gli update applicati dentro al container non sono persistenti.

Nota: l’esame AZ-800 (passing score 700/1000) è in ritiro il 30 settembre 2026; per dettagli su cmdlet, tag delle immagini e limiti verifica sempre la documentazione ufficiale Microsoft.