Contenitori riservati (anteprima) con Servizio Azure Kubernetes (AKS)

I contenitori riservati offrono un set di funzionalità e funzionalità per proteggere ulteriormente i carichi di lavoro dei contenitori standard per ottenere obiettivi di sicurezza dei dati, privacy dei dati e integrità del codice di runtime più elevati. Servizio Azure Kubernetes include contenitori riservati (CoCo) (anteprima).

I contenitori riservati si basano su contenitori Kata Confidential e sulla crittografia basata su hardware per crittografare la memoria del contenitore. I contenitori riservati nel servizio Azure Kubernetes usano SEV-SNP AMD e attualmente supportano solo Azure Linux. Stabiliscono un nuovo livello di riservatezza dei dati evitando che i dati in memoria durante il calcolo siano in formato non crittografato e leggibile. L'attendibilità viene ottenuta nel contenitore tramite l'attestazione hardware, consentendo l'accesso ai dati crittografati da entità attendibili.

AKS supporta due funzionalità basate su Kata Containers: contenitori confidenziali e sandboxing dei pod. Mentre la sandbox dei pod protegge il pod dall'esecuzione in un kernel condiviso, non protegge il pod dagli attacchi a livello di amministratore. I contenitori riservati offrono un ulteriore livello di protezione avanzata.

Screenshot del diagramma dell'architettura che mostra i contenitori riservati e la sandbox dei pod nel servizio Azure Kubernetes.

Che cosa rende un contenitore riservato:

  • Trasparenza: è possibile visualizzare e verificare che l'ambiente contenitore riservato che esegue l'applicazione sensibile sia sicuro. Microsoft rende open source tutti i componenti della Trusted Computing Base (TCB).
  • Verificabilità: è possibile verificare e vedere quale versione del pacchetto dell'ambiente CoCo, incluso il sistema operativo guest Linux e tutti i componenti, è attualmente in uso. Microsoft firma il sistema operativo guest e l'ambiente di runtime del contenitore, in modo che sia possibile verificarli mediante attestazione. Microsoft pubblica anche un algoritmo di hash sicuro (SHA) delle build del sistema operativo guest per offrire solide garanzie di verificabilità e controllo.
  • Attestazione completa: la CPU misura integralmente tutto ciò che fa parte del TEE, consentendone la verifica remota. Il report hardware del processore AMD SEV-SNP riflette i livelli del contenitore e l'hash della configurazione del runtime del contenitore tramite le attestazioni. L'applicazione può ottenere localmente il report sull'hardware, incluso il report relativo all'immagine del sistema operativo guest e al runtime del container.
  • Integrità del codice: l'applicazione 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: architetture di sicurezza che presuppongono il principio del privilegio minimo e il massimo livello di isolamento rispetto a tutte le parti non attendibili, inclusi gli amministratori dei clienti e dei tenant. Include la protezione avanzata dell'accesso del piano di controllo Kubernetes esistente (kubelet) esistente ai pod riservati.

Usando queste funzionalità con altre misure di sicurezza o controlli di protezione dei dati come parte dell'architettura complessiva, è possibile soddisfare i requisiti normativi, di settore o di conformità della governance per proteggere le informazioni riservate.

Questo articolo illustra la funzionalità Contenitori riservati e come implementare e configurare le attività seguenti:

  • Distribuire o aggiornare un cluster AKS con l'interfaccia della riga di comando di Azure.
  • Aggiungi un'annotazione al file YAML del pod per indicare che il pod viene eseguito come container confidenziale.
  • Aggiungere un criterio di sicurezza al pod YAML.
  • Distribuisci l'applicazione in un ambiente di calcolo riservato.

Scenari supportati

I contenitori riservati (anteprima) sono appropriati per gli scenari di distribuzione che coinvolgono dati sensibili. Ad esempio, informazioni personali (PII) o dati che richiedono una sicurezza avanzata per la conformità alle normative. Alcuni scenari comuni con i contenitori sono:

  • Eseguire analisi dei Big Data usando Apache Spark per il riconoscimento dei modelli di frode nel settore finanziario.
  • Esecuzione di strumenti di esecuzione GitHub self-hosted per firmare in modo sicuro il codice come parte delle procedure DevOps di integrazione continua e distribuzione continua (CI/CD).
  • Inferenza e training di modelli di Machine Learning usando un set di dati crittografato da un'origine attendibile. Decrittografa solo all'interno di un ambiente contenitore riservato per mantenere la privacy.
  • Creazione di camere bianche di Big Data per la corrispondenza di ID come parte del calcolo multiparte in settori come la vendita al dettaglio con pubblicità digitale.
  • Creazione di zone di destinazione Zero Trust di confidential computing per soddisfare le normative sulla privacy per le migrazioni di applicazioni al cloud.

Limitations

Considerazioni

  • Il tempo di avvio dei pod aumenta rispetto ai pod runc e ai pod isolati dal kernel.
  • Le immagini di contenitore che usano lo schema del manifest dell'immagine Docker versione 1 (v1) non sono supportate.
  • Per usare contenitori temporanei e altri metodi di risoluzione dei problemi, ad esempio exec in un contenitore, nell'output del log del contenitore e stdio, è necessario modificare i criteri e ridistribuirlo per abilitare ExecProcessRequest, ReadStreamRequestWriteStreamRequest, e CloseStdinRequest.
  • Poiché i criteri di sicurezza codificano le misurazioni del livello immagine del contenitore, non usare il latest tag quando si specificano i contenitori.
  • Servizi, servizi di bilanciamento del carico ed EndpointSlices supportano solo il protocollo TCP.
  • Il generatore di criteri supporta solo i pod che usano indirizzi IPv4.
  • Non è possibile modificare le variabili di ambiente dei pod in base a ConfigMaps e Segreti dopo la distribuzione del pod.
  • La risorsa requests nei manifesti dei pod non è supportata. Usare invece la risorsa limits perché containerd non passa le richieste allo shim Kata.
  • I log di terminazione dei pod non sono supportati. Sebbene i pod scrivano i log di terminazione in /dev/termination-log (o in un percorso personalizzato impostato nel manifest del pod), l'host e il kubelet non possono leggere tali log e le modifiche che il pod apporta a quel file non si riflettono sull'host.
  • L'accesso alla rete host non è supportato. Non è possibile accedere direttamente alla configurazione di rete host dall'interno della macchina virtuale pod.
  • Microsoft Defender per i contenitori non valuta i pod che usano il runtime Kata.
  • I container Kata potrebbero non raggiungere i limiti di prestazioni IOPS che i container tradizionali raggiungono con File di Azure e con unità SSD locali ad alte prestazioni.

Panoramica dell'allocazione delle risorse

È importante comprendere il comportamento di allocazione delle risorse di memoria e processore in questa versione.

  • CPU: Lo shim assegna una vCPU al sistema operativo di base all'interno del pod. Se non si specifica la risorsa limits, i carichi di lavoro non dispongono di condivisioni CPU separate assegnate e la vCPU viene condivisa con tale carico di lavoro. Se si specificano limiti di CPU, il sistema alloca in modo esplicito le condivisioni CPU per i carichi di lavoro.
  • Memoria, gestore Kata-CC: il gestore alloca 2 GB di memoria al sistema operativo della macchina virtuale di utilità (UVM) più una quantità di memoria pari alla risorsa limits specificata nel file manifesto YAML. Se non si specifica un limite, il gestore crea una macchina virtuale da 2 GB senza memoria implicita per i contenitori.
  • Memoria, gestore Kata: il gestore alloca 256 MB di memoria di base al sistema operativo UVM più memoria uguale alla risorsa limits specificata nel manifesto YAML. Se non si specifica un limite, il gestore aggiunge un limite implicito di 1.792 MB, con conseguente vm da 2 GB con 1.792 MB di memoria implicita per i contenitori.

In questa versione, la specifica delle richieste di risorse nei manifesti del pod non è supportata. il contenitore non passa le richieste allo shim Kata e, di conseguenza, la prenotazione delle risorse in base alle richieste di risorse manifesto del pod non viene implementata. Usare la risorsa limits anziché la risorsa requests per allocare risorse di memoria o CPU per carichi di lavoro o contenitori.

Con il file system del contenitore locale supportato dalla memoria della macchina virtuale, la scrittura nel file system del contenitore (inclusa la registrazione) può riempire la memoria disponibile fornita nel pod. Questa condizione può causare potenziali arresti anomali del pod.

Passaggi successivi

  • Last updated on