Contenitori riservati (anteprima) nel servizio Azure Kubernetes

Con l'aumento dello sviluppo di applicazioni native del cloud, è necessario proteggere anche i carichi di lavoro in esecuzione negli ambienti cloud. La containerizzazione dei carichi di lavoro costituisce un componente chiave per questo modello di programmazione e quindi la protezione del contenitore è fondamentale per l'esecuzione riservata nel cloud.

I contenitori riservati nel servizio Azure Kubernetes consentono l'isolamento a livello di contenitore nei carichi di lavoro Kubernetes. Si tratta di un'aggiunta alla suite di prodotti di confidential computing di Azure e usa la crittografia di memoria SEV-SNP AMD per proteggere i contenitori in fase di esecuzione.

I contenitori riservati sono interessanti per gli scenari di distribuzione che coinvolgono dati sensibili ( ad esempio, dati personali o dati con sicurezza avanzata necessaria per la conformità alle normative).

Che cosa rende un contenitore riservato?

In linea con le linee guida stabilite dal Confidential Computing Consortium, di cui Microsoft è un membro fondatore, i contenitori riservati devono soddisfare i requisiti seguenti:

• Trasparenza: è possibile visualizzare e verificare la sicurezza dell'ambiente dei contenitori riservati in cui viene condivisa l'applicazione sensibile. Tutti i componenti della Trusted Computing Base (TCB) devono essere open source.
• Verificabilità: è possibile verificare e visualizzare la versione del pacchetto di ambiente CoCo, incluso il sistema operativo guest Linux e controllare che tutti i componenti siano aggiornati. Microsoft accede al sistema operativo guest e all'ambiente di runtime del contenitore per le verifiche tramite attestazione. Rilascia anche un algoritmo hash sicuro (SHA) di compilazioni del sistema operativo guest per creare una storia di controllo e di verificabilità delle stringhe.
• Attestazione completa: qualsiasi elemento che fa parte dell'ambiente di esecuzione attendibile deve essere misurato completamente dalla CPU con la possibilità di verifiche in remoto. Il report hardware del processore AMD SEV-SNP deve riflettere i livelli del contenitore e l'hash della configurazione del runtime del contenitore tramite attestazioni. L'applicazione può recuperare il report hardware in locale, incluso il report che riflette l'immagine del sistema operativo guest e il runtime del contenitore.
• Integrità del codice: l'imposizione del runtime è sempre disponibile tramite criteri definiti dal cliente per contenitori e configurazione del contenitore, ad esempio criteri non modificabili e firma del contenitore.
• Isolamento dall'operatore: progettazioni di sicurezza che presuppongono privilegi minimi e la massima schermatura di isolamento da tutte le parti non attendibili, inclusi gli amministratori di clienti/tenant. Include la protezione avanzata dell'accesso del piano di controllo Kubernetes esistente (kubelet) esistente ai pod riservati.

Tuttavia, con queste funzionalità di riservatezza, il prodotto dovrebbe anche semplificarne l'uso: supporta tutti i contenitori Linux non modificato con conformità alle funzionalità Kubernetes elevate. Supporta inoltre pool di nodi eterogenei (GPU, nodi per utilizzo generico) in un singolo cluster per ottimizzare i costi.

Su cosa sono basati i contenitori riservati nel servizio Azure Kubernetes?

In linea con l'impegno di Microsoft per la community open source, lo stack sottostante per i contenitori riservati usa l'agente Kata CoCo come agente in esecuzione nel nodo che ospita il pod che esegue il carico di lavoro riservato. Considerate le molte tecnologie TEE che richiedono un limite tra l'host e il guest, i contenitori Kata sono la base per il lavoro iniziale Kata CoCo. Microsoft ha anche contribuito alla community Kata Coco per alimentare i contenitori in esecuzione all'interno di una macchina virtuale di utilità riservata.

Il contenitore riservato Kata si trova all'interno dell'host contenitore del servizio Azure Kubernetes Linux di Azure. Azure Linux e Cloud Hypervisor VMM (Virtual Machine Monitor) è il software di spazio utente/utente finale usato per la creazione e la gestione della durata delle macchine virtuali.

Isolamento a livello di contenitore nel servizio Azure Kubernetes

Per impostazione predefinita, tutti i carichi di lavoro del servizio Azure Kubernetes condividono lo stesso kernel e lo stesso amministratore del cluster. Con l'anteprima di Pod Sandboxing nel servizio Azure Kubernetes, l'isolamento è stato potenziato con la possibilità di fornire l'isolamento del kernel per i carichi di lavoro sullo stesso nodo del servizio Azure Kubernetes. Altre informazioni su questa funzionalità sono disponibili qui. I contenitori riservati sono il passaggio successivo di questo isolamento e usano le funzionalità di crittografia della memoria delle macchine virtuali SEV-SNP AMD sottostanti. Queste macchine virtuali sono di dimensioni DCa_cc e ECa_cc con la possibilità di esporre la radice di attendibilità dell'hardware per i pod distribuiti.

Operazioni preliminari

Per iniziare e per altre informazioni sugli scenari supportati, vedere la documentazione del servizio Azure Kubernetes qui.

Passaggio successivo

Distribuire un contenitore riservato nel servizio Azure Kubernetes.