Proteggere i contenitori di Windows

Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

I contenitori prestano le dimensioni ridotte dell'immagine al fatto che possono fare affidamento sull'host per fornire accesso limitato a varie risorse. Se il contenitore sa che l'host sarà in grado di fornire le funzionalità necessarie per eseguire un set specifico di azioni, il contenitore non deve includere il software pertinente nell'immagine di base. L'estensione della condivisione delle risorse che si verifica, tuttavia, può avere un impatto significativo sulle prestazioni e sulla sicurezza del contenitore. Se sono condivise troppe risorse, l'applicazione può anche essere eseguita come processo nell'host. Se le risorse sono condivise troppo poco, il contenitore diventa indistinguibile da una macchina virtuale. Entrambe le configurazioni sono applicabili a molti scenari, ma la maggior parte degli utenti che usano i contenitori in genere optano per qualcosa al centro.

La sicurezza di un contenitore di Windows deriva dal grado di condivisione che si verifica con il relativo host. Il limite di sicurezza di un contenitore è costituito dai meccanismi di isolamento che separano il contenitore dall'host. Soprattutto, questi meccanismi di isolamento definiscono quali processi nel contenitore possono interagire con l'host. Se la progettazione di un contenitore consente a un processo con privilegi elevati (amministratore) di interagire con l'host, Microsoft non considera questo contenitore un limite di sicurezza affidabile.

Contenitori di Windows Server e contenitori Linux

I contenitori di Windows Server isolati dal processo e i contenitori Linux condividono gradi di isolamento simili. Per entrambi i tipi di contenitore, lo sviluppatore deve presupporre qualsiasi attacco che può essere eseguito tramite un processo con privilegi elevati nell'host può essere eseguito anche tramite un processo con privilegi elevati nel contenitore. Entrambi operano tramite le funzionalità primitive offerte dai rispettivi kernel host. Le immagini del contenitore vengono compilate contenenti file binari in modalità utente che usano le API fornite dal kernel host. Il kernel host offre le stesse funzionalità di isolamento e gestione delle risorse per ogni contenitore in esecuzione nello spazio utente. Se il kernel viene compromesso, quindi ogni contenitore che condivide tale kernel.

La progettazione fondamentale dei contenitori di Linux e Windows Server è la sicurezza per la flessibilità. I contenitori Windows Server e Linux si basano sui componenti primitivi forniti dal sistema operativo. Questa operazione offre la flessibilità necessaria per la condivisione di risorse e spazi dei nomi tra contenitori, ma aggiunge complessità aggiuntive che apre la porta per lo sfruttamento. In generale, non si considera che il kernel sia un limite di sicurezza sufficiente per carichi di lavoro multi-tenant ostili.

Isolamento del kernel con contenitori isolati dall'hypervisor

I contenitori con isolamento hypervisor offrono un livello di isolamento superiore rispetto ai contenitori Windows Server o Linux isolati dal processo e sono considerati limiti di sicurezza affidabili. I contenitori con isolamento hypervisor sono costituiti da un contenitore di Windows Server incapsulato in una macchina virtuale ultralight e quindi eseguito insieme al sistema operativo host tramite l'hypervisor di Microsoft. L'hypervisor fornisce l'isolamento a livello di hardware che include un limite di sicurezza estremamente affidabile tra l'host e altri contenitori. Anche se un exploit dovesse eseguire l'escape del contenitore di Windows Server, sarebbe contenuto all'interno della macchina virtuale isolata dall'hypervisor.

Né i contenitori Windows Server né i contenitori Linux forniscono ciò che Microsoft considera un limite di sicurezza affidabile e non deve essere usato in scenari multi-tenant ostili. Un contenitore deve essere limitato a una macchina virtuale dedicata per impedire a un processo di contenitore non autorizzato di interagire con l'host o altri tenant. L'isolamento hypervisor consente questo grado di separazione, offrendo anche diversi miglioramenti delle prestazioni rispetto alle macchine virtuali tradizionali. Pertanto, è consigliabile che in scenari multi-tenant ostili, i contenitori con isolamento hypervisor devono essere il contenitore preferito.

Criteri di manutenzione della sicurezza dei contenitori

Microsoft si impegna a applicare patch a tutti gli exploit e i escape che interrompono il limite di isolamento stabilito di qualsiasi tipo di contenitore di Windows. Tuttavia, solo gli exploit che interrompono un limite di sicurezza vengono gestiti tramite il processo di Microsoft Security Response Center (MSRC). Solo i contenitori con isolamento hypervisor forniscono un limite di sicurezza e i contenitori isolati dal processo non lo fanno. L'unico modo per generare un bug per un escape del contenitore isolato dal processo è se un processo non amministratore può ottenere l'accesso all'host. Se un exploit usa un processo di amministratore per eseguire l'escape del contenitore, Microsoft lo considera come un bug non di sicurezza e lo patchrà in base al normale processo di manutenzione. Se un exploit usa un processo non amministratore per eseguire un'azione che viola un limite di sicurezza, Microsoft lo esaminerà in base ai criteri di manutenzione di sicurezza stabiliti.

Cosa rende ostile un carico di lavoro multi-tenant?

Esistono ambienti multi-tenant quando più carichi di lavoro operano su un'infrastruttura e risorse condivise. Se uno o più carichi di lavoro in esecuzione in un'infrastruttura non possono essere considerati attendibili, l'ambiente multi-tenant è considerato ostile. Entrambi i contenitori Windows Server e Linux condividono il kernel host, quindi qualsiasi exploit eseguito su un singolo contenitore può influire su tutti gli altri carichi di lavoro in esecuzione nell'infrastruttura condivisa.

È possibile adottare misure per ridurre la probabilità che si verifichi un exploit, ad esempio usando i criteri di sicurezza dei pod, AppArmor e il controllo degli accessi in base al ruolo, ma non forniscono protezione garantita da un utente malintenzionato. È consigliabile seguire le procedure consigliate per l'isolamento del cluster per qualsiasi scenario multi-tenant.

Quando usare gli account utente Container Amministrazione e ContainerUser

I contenitori di Windows Server offrono due account utente predefiniti, ContainerUser e Container Amministrazione istrator, ognuno con uno scopo specifico. L'account Container Amministrazione istrator consente di usare il contenitore per scopi amministrativi: l'installazione di servizi e software (ad esempio l'abilitazione di IIS all'interno di un contenitore), la modifica della configurazione e la creazione di nuovi account. Queste attività sono importanti per diversi scenari IT che possono essere eseguiti in ambienti di distribuzione locali personalizzati.

L'account ContainerUser esiste per tutti gli altri scenari in cui non sono necessari privilegi di amministratore in Windows. Ad esempio, in Kubernetes se l'utente è Container Amministrazione istrator e hostvolumes possono essere montati nel pod, l'utente potrebbe montare la cartella .ssh e aggiungere una chiave pubblica. Poiché ContainerUser questo esempio non sarebbe possibile. Si tratta di un account utente con restrizioni progettato esclusivamente per le applicazioni che non devono interagire con l'host. È consigliabile che quando si distribuisce un contenitore di server Windows in qualsiasi ambiente multi-tenant eseguito dall'applicazione tramite l'account ContainerUser. In un ambiente multi-tenant è sempre consigliabile seguire il principio dei privilegi minimi perché se un utente malintenzionato compromette il carico di lavoro, la risorsa condivisa e i carichi di lavoro adiacenti hanno anche una minore probabilità di essere interessati. L'esecuzione di contenitori con l'account ContainerUser riduce notevolmente la probabilità che l'ambiente venga compromesso nel suo complesso. Tuttavia, questo non fornisce ancora un limite di sicurezza affidabile, quindi quando la sicurezza è un problema è consigliabile usare contenitori isolati da hypervisor.

Per modificare l'account utente, è possibile usare l'istruzione U edizione Standard R nel dockerfile:

USER ContainerUser

In alternativa, è possibile creare un nuovo utente:

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

Servizi Windows

I servizi Microsoft Windows, noti in precedenza come servizi NT, consentono di creare applicazioni eseguibili di lunga durata in esecuzione in sessioni Windows dedicate. Questi servizi possono essere avviati automaticamente all'avvio del sistema operativo, possono essere sospesi e riavviati e non mostrano alcuna interfaccia utente. È anche possibile eseguire i servizi nel contesto di sicurezza di un account utente specifico diverso dall'utente connesso o dall'account computer predefinito.

Quando si crea un contenitore e si protegge un carico di lavoro eseguito come servizio Windows, è necessario tenere presenti alcune considerazioni aggiuntive. In primo luogo, il ENTRYPOINT del contenitore non sarà il carico di lavoro perché il servizio viene eseguito come processo in background, in ENTRYPOINT genere sarà uno strumento come monitoraggio del servizio) o monitoraggio log. In secondo luogo, l'account di sicurezza in cui opera il carico di lavoro verrà configurato dal servizio non dalla direttiva U edizione Standard R nel dockerfile. È possibile controllare l'account in cui verrà eseguito il servizio eseguendo Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartName.

Ad esempio, quando si ospita un'applicazione Web IIS usando l'immagine ENTRYPOINT ASP.NET (Registro artefatti Microsoft) del contenitore è "C:\\ServiceMonitor.exe", "w3svc". Questo strumento può essere usato per configurare il servizio IIS e quindi monitora il servizio per assicurarsi che rimanga in esecuzione e venga chiuso, arrestando così il contenitore, se il servizio si arresta per qualsiasi motivo. Per impostazione predefinita, il servizio IIS e quindi l'applicazione Web viene eseguita con un account con privilegi limitati all'interno del contenitore, ma lo strumento di monitoraggio del servizio richiede privilegi amministrativi per configurare e monitorare il servizio.