Sandboxing dei pod (anteprima) con il servizio Azure Kubernetes (AKS)

Per aiutare a proteggere i carichi di lavoro dei contenitori da codice non attendibile o potenzialmente dannoso, il servizio Azure Kubernetes include ora un meccanismo chiamato Sandboxing dei pod (anteprima). Il Sandboxing dei pod fornisce un limite di isolamento tra l'applicazione del contenitore e il kernel condiviso e le risorse di calcolo dell'host del contenitore. Ad esempio CPU, memoria e rete. Il Sandboxing dei pod integra altre misure di sicurezza o controlli di protezione dei dati con l'architettura complessiva, per soddisfare i requisiti di conformità normativa, di settore o della governance per la protezione delle informazioni riservate.

Questo articolo aiuta a comprendere questa nuova funzionalità e a come implementarla.

Prerequisiti

• Interfaccia della riga di comando di Azure versione 2.44.1 o successiva. Eseguire az --version per trovare la versione ed eseguire az upgrade per aggiornare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.

• Estensione aks-preview dell'interfaccia della riga di comando di Azure versione 0.5.123 o successiva.

• Registrare la funzionalità KataVMIsolationPreview nella sottoscrizione di Azure.

• Il servizio Azure Kubernetes supporta il Sandboxing dei pod (anteprima) nella versione 1.24.0 e successive con tutti i plug-in di rete del servizio Azure Kubernetes.

• Per gestire un cluster Kubernetes, usare il client della riga di comando Kubernetes kubectl. Azure Cloud Shell include kubectl. È possibile installare kubectl in locale usando il comando az aks install-cli.

Installare l'estensione dell'interfaccia della riga di comando di Azure aks-preview

Importante

Le funzionalità di anteprima del servizio Azure Kubernetes sono disponibili in modalità self-service e opzionale. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime del servizio Azure Kubernetes sono parzialmente coperte dal supporto clienti con la massima diligenza possibile. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione. Per altre informazioni, vedere gli articoli di supporto seguenti:

• Criteri di supporto del Servizio Azure Kubernetes (AKS)
• Domande frequenti relative al supporto tecnico di Azure

Per installare l'estensione aks-preview, eseguire il comando seguente:

az extension add --name aks-preview

Eseguire il comando seguente per aggiornare alla versione più recente dell'estensione rilasciata:

az extension update --name aks-preview

Registrare il flag di funzionalità KataVMIsolationPreview

Registrare il flag di funzionalità KataVMIsolationPreview usando il comando az feature register come illustrato nell'esempio seguente:

az feature register --namespace "Microsoft.ContainerService" --name "KataVMIsolationPreview"

Sono necessari alcuni minuti per visualizzare lo stato Registered. Verificare lo stato della registrazione usando il comando az feature show:

az feature show --namespace "Microsoft.ContainerService" --name "KataVMIsolationPreview"

Quando lo stato passa a Registrato, aggiornare la registrazione del provider di risorse Microsoft.ContainerService usando il comando az provider register:

az provider register --namespace "Microsoft.ContainerService"

Limiti

Di seguito sono riportati i vincoli con questa anteprima di Sandboxing dei pod (anteprima):

• I contenitori Kata potrebbero non raggiungere i limiti di prestazioni delle operazioni di I/O al secondo che i container tradizionali possono raggiungere su File di Azure e SSD locali con prestazioni elevate.

• Microsoft Defender per contenitori non supporta la valutazione dei pod di runtime Kata.

• La rete host Kata non è supportata.

• Il servizio Azure Kubernetes non supporta Container Storage Interface e driver Secrets Store CSI in questa versione di anteprima.

Funzionamento

Per ottenere questa funzionalità nel servizio Azure Kubernetes, Contenitori Kata in esecuzione nell'host del contenitore Linux di Azure per il servizio Azure Kubernetes offre un isolamento imposto dall'hardware. Il Sandboxing dei pod estende i vantaggi dell'isolamento hardware, ad esempio un kernel separato per ogni pod Kata. L'isolamento hardware alloca le risorse per ogni pod e non le condivide con altri contenitori Kata o contenitori dello spazio dei nomi in esecuzione nello stesso host.

L'architettura della soluzione si basa sui componenti seguenti:

• L'host contenitore Linux di Azure per il servizio Azure Kubernetes
• Microsoft Hyper-V Hypervisor
• Kernel Linux Dom0 ottimizzato di Azure
• Cloud-Hypervisor Virtual Machine Monitor (VMM) Open source
• Integrazione con il framework contenitore Kata

La distribuzione del Sandboxing dei pod con i contenitori Kata è simile al flusso di lavoro standard di Containerd per la distribuzione dei contenitori. La distribuzione include le opzioni kata-runtime che è possibile definire nel modello di pod.

Per usare questa funzionalità con un pod, l'unica differenza consiste nell'aggiungere runtimeClassName kata-mshv-vm-isolation alla specifica del pod.

Quando un pod usa il kata-mshv-vm-isolation runtimeClass, crea una macchina virtuale da usare come sandbox dei pod per ospitare i contenitori. La memoria predefinita della macchina virtuale è 2 GB e la CPU predefinita è un core se il manifesto della risorsa contenitore (containers[].resources.limits) non specifica un limite per la CPU e la memoria. Quando si specifica un limite per la CPU o la memoria nel manifesto della risorsa contenitore, la macchina virtuale ha containers[].resources.limits.cpu con l'argomento 1 da usare uno + xCPU e containers[].resources.limits.memory con l'argomento 2 per specificare 2 GB + yMemory. I contenitori possono usare la CPU e la memoria solo entro i limiti dei contenitori stessi. containers[].resources.requests viene ignorato in questa anteprima mentre si lavora per ridurre il sovraccarico della CPU e della memoria.

Distribuire un nuovo cluster

Seguire questa procedura per distribuire un cluster del servizio Azure Kubernetes Linux usando l'interfaccia della riga di comando di Azure.

1. Creare un cluster del servizio Azure Kubernetes usando il comando az aks create e specificando i parametri seguenti:

   • --workload-runtime: specificare KataMshvVmIsolation per abilitare la funzionalità Sandboxing dei pod nel pool di nodi. Con questo parametro, questi altri parametri soddisfano i requisiti seguenti. In caso contrario, il comando non riesce e segnala un problema con i parametri corrispondenti.
   • --os-sku: AzureLinux. Solo lo SKU del sistema operativo Linux di Azure supporta questa funzionalità in questa versione di anteprima.
   • --node-vm-size: qualsiasi dimensione di macchina virtuale di Azure che sia una VM di seconda generazione e che supporti la virtualizzazione annidata. Ad esempio, le macchine virtuali Dsv3.

   L'esempio seguente crea un cluster denominato myAKSCluster con un nodo nel myResourceGroup:

   az aks create 
       --name myAKSCluster \
       --resource-group myResourceGroup \
       --os-sku AzureLinux \
       --workload-runtime KataMshvVmIsolation \
       --node-vm-size Standard_D4s_v3 \
       --node-count 1 \
       --generate-ssh-keys
   

2. Eseguire il comando seguente per ottenere le credenziali di accesso per il cluster Kubernetes. Usare il comando az aks get-credentials e sostituire i valori del nome del cluster e il nome del gruppo di risorse.

   az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
   

3. Elencare tutti i pod in tutti gli spazi dei nomi usando il comando kubectl get pods.

   kubectl get pods --all-namespaces
   

Eseguire la distribuzione in un cluster esistente

Per usare questa funzionalità con un cluster del servizio Azure Kubernetes esistente, è necessario soddisfare i requisiti seguenti:

• Seguire la procedura per registrare il flag di funzionalità KataVMIsolationPreview.
• Verificare che il cluster esegua Kubernetes versione 1.24.0 e successive.

Usare il comando seguente per abilitare il Sandboxing dei pod (anteprima) creando un pool di nodi per ospitarlo.

1. Aggiungere un pool di nodi al cluster del servizio Azure Kubernetes usando il comando az aks nodepool add. Specificare i seguenti parametri:

   • --resource-group: immettere il nome di un gruppo di risorse esistente in cui creare il cluster del servizio Azure Kubernetes.
   • --cluster-name: immettere un nome univoco per il cluster del servizio Azure Kubernetes, ad esempio myAKSCluster.
   • --name: immettere un nome univoco per il pool di nodi del cluster, ad esempio nodepool2.
   • --workload-runtime: specificare KataMshvVmIsolation per abilitare la funzionalità Sandboxing dei pod nel pool di nodi. Insieme al parametro --workload-runtime, questi altri parametri soddisfano i requisiti seguenti. In caso contrario, il comando non riesce e segnala un problema con i parametri corrispondenti.
     • --os-sku: AzureLinux. Solo lo SKU del sistema operativo Linux di Azure supporta questa funzionalità nella versione di anteprima.
     • --node-vm-size: qualsiasi dimensione di macchina virtuale di Azure che sia una VM di seconda generazione e che supporti la virtualizzazione annidata. Ad esempio, le macchine virtuali Dsv3.

   L'esempio seguente aggiunge un pool di nodi a myAKSCluster con un nodo in nodepool2 in myResourceGroup:

   az aks nodepool add --cluster-name myAKSCluster --resource-group myResourceGroup --name nodepool2 --os-sku AzureLinux --workload-runtime KataMshvVmIsolation --node-vm-size Standard_D4s_v3
   

2. Eseguire il comando az aks update per abilitare il sandboxing dei pod (anteprima) nel cluster.

   az aks update --name myAKSCluster --resource-group myResourceGroup
   

Distribuire un'applicazione attendibile

Per illustrare la distribuzione di un'applicazione attendibile nel kernel condiviso nel cluster del servizio Azure Kubernetes, seguire questa procedura.

1. Creare un file denominato trusted-app.yaml per descrivere un pod attendibile e quindi incollare il manifesto seguente.

   kind: Pod
   apiVersion: v1
   metadata:
     name: trusted
   spec:
     containers:
     - name: trusted
       image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
       command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]
   

2. Distribuire il pod Kubernetes eseguendo il comando kubectl apply e specificare il file trusted-app.yaml:

   kubectl apply -f trusted-app.yaml
   

   L'output del comando è simile all'esempio seguente:

   pod/trusted created
   

Distribuire un'applicazione non attendibile

Per illustrare la distribuzione di un'applicazione non attendibile nella sandbox del pod sul cluster del servizio Azure Kubernetes, seguire questa procedura.

1. Creare un file denominato untrusted-app.yaml per descrivere un pod non attendibile e quindi incollare il manifesto seguente.

   kind: Pod
   apiVersion: v1
   metadata:
     name: untrusted
   spec:
     runtimeClassName: kata-mshv-vm-isolation
     containers:
     - name: untrusted
       image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
       command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]
   

   Il valore per runtimeClassNameSpec è kata-mhsv-vm-isolation.

2. Distribuire il pod Kubernetes eseguendo il comando kubectl apply e specificare il file untrusted-app.yaml:

   kubectl apply -f untrusted-app.yaml
   

   L'output del comando è simile all'esempio seguente:

   pod/untrusted created
   

Verificare la configurazione dell'isolamento del kernel

1. Per accedere a un contenitore all'interno del cluster del servizio Azure Kubernetes, avviare una sessione della shell eseguendo il comando kubectl exec. In questo esempio si accede al contenitore all'interno del pod non attendibile.

   kubectl exec -it untrusted -- /bin/bash
   

   Kubectl si connette al cluster, esegue /bin/sh all'interno del primo contenitore all'interno del pod non attendibile e inoltra i flussi di input e output del terminale al processo del contenitore. È anche possibile avviare una sessione della shell nel contenitore che ospita il pod attendibile.

2. Dopo aver avviato una sessione della shell nel contenitore del pod non attendibile, è possibile eseguire comandi per verificare che il contenitore non attendibile sia in esecuzione in una sandbox del pod. Si noterà che ha una versione del kernel diversa rispetto al contenitore attendibile all'esterno della sandbox.

   Per visualizzare la versione del kernel, eseguire il comando seguente:

   uname -r
   

   L'esempio seguente è simile all'output del kernel sandbox del pod:

   root@untrusted:/# uname -r
   5.15.48.1-8.cm2
   

3. Avviare una sessione della shell nel contenitore del pod attendibile per verificare l'output del kernel:

   kubectl exec -it trusted -- /bin/bash
   

   Per visualizzare la versione del kernel, eseguire il comando seguente:

   uname -r
   

   L'esempio seguente è simile all'output della macchina virtuale che esegue il pod attendibile, che è un kernel diverso rispetto al pod non attendibile in esecuzione all'interno della sandbox del pod:

   5.15.80.mshv2-hvl1.m2
   

Pulizia

Al termine della valutazione di questa funzionalità, per evitare addebiti di Azure, pulire le risorse non necessarie. Se è stato distribuito un nuovo cluster come parte della valutazione o del test, è possibile eliminare il cluster usando il comando az aks delete.

az aks delete --resource-group myResourceGroup --name myAKSCluster

Se è stato abilitato il Sandboxing dei pod (anteprima) in un cluster esistente, è possibile rimuovere i pod usando il comando kubectl delete pod.

kubectl delete pod pod-name

Passaggi successivi

Altre informazioni sugli host dedicati di Azure per i nodi con il cluster del servizio Azure Kubernetes per usare l'isolamento hardware e il controllo sugli eventi di manutenzione della piattaforma Azure.