Contenitori riservati (anteprima) con servizio Azure Kubernetes (servizio Azure Kubernetes)

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 (servizio Azure Kubernetes) include contenitori riservati (anteprima) nel servizio Azure Kubernetes.

I contenitori riservati si basano su Kata Confidential Containers e sulla crittografia basata su hardware per crittografare la memoria del contenitore. Stabilisce un nuovo livello di riservatezza dei dati impedendo ai dati in memoria durante il calcolo di essere 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.

Insieme a Pod Sandboxing, è possibile eseguire carichi di lavoro sensibili isolati in Azure per proteggere i dati e i carichi di lavoro. Cosa rende riservato un contenitore:

• Trasparenza: l'ambiente contenitore riservato in cui è condivisa l'applicazione sensibile, è possibile visualizzare e verificare se è sicura. 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 tutti i componenti sono aggiornati. Microsoft accede al sistema operativo guest e all'ambiente di runtime del contenitore per le verifiche tramite l'attestazione. Rilascia anche un algoritmo hash sicuro (SHA) di compilazioni del sistema operativo guest per creare una storia di controllo e di audibilità delle stringhe.
• Attestazione completa: qualsiasi elemento che fa parte del T edizione Enterprise deve essere misurato completamente dalla CPU con la possibilità di verificare in remoto. Il report hardware del processore AMD edizione Standard V-SNP riflette i livelli del contenitore e l'hash della configurazione del runtime del contenitore tramite le attestazioni di attestazione. 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 schermatura di isolamento più elevato 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) ai pod riservati.

Con altre misure di sicurezza o controlli di protezione dei dati, come parte dell'architettura complessiva, queste funzionalità consentono di soddisfare i requisiti normativi, di settore o di conformità della governance per la protezione delle informazioni riservate.

Questo articolo illustra la funzionalità Contenitori riservati e come implementare e configurare quanto segue:

• Distribuire o aggiornare un cluster del servizio Azure Kubernetes usando l'interfaccia della riga di comando di Azure
• Aggiungere un'annotazione al pod YAML per contrassegnare il pod come eseguito come contenitore riservato
• Aggiungere un criterio di sicurezza al pod YAML
• Abilitare l'applicazione dei criteri di sicurezza
• Distribuire l'applicazione in confidential computing

Scenari supportati

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

• Eseguire analisi dei Big Data usando Apache Spark per il riconoscimento dei criteri 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 sale pulite 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.

Considerazioni

Di seguito sono riportate alcune considerazioni relative a questa anteprima dei contenitori riservati:

• Aumento del tempo di avvio dei pod rispetto ai pod runc e ai pod isolati dal kernel.
• Le immagini del contenitore versione 1 non sono supportate.
• Aggiornamenti ai segreti e alla configurazione Mappe non vengono riflesse nel guest.
• I contenitori temporanei e altri metodi di risoluzione dei problemi, ad exec esempio in un contenitore, gli output dei log dai contenitori e stdio (ReadStreamRequest e WriteStreamRequest) richiedono una modifica e una ridistribuzione dei criteri.
• Lo strumento generatore di criteri non supporta i tipi di distribuzione cronjob.
• A causa delle misurazioni del livello immagine del contenitore codificate nei criteri di sicurezza, non è consigliabile usare il latest tag quando si specificano i contenitori.
• I servizi, i servizi di bilanciamento del carico e gli endpointSlice supportano solo il protocollo TCP.
• Tutti i contenitori in tutti i pod nei cluster devono essere configurati in imagePullPolicy: Always.
• Il generatore di criteri supporta solo i pod che usano indirizzi IPv4.
• I valori config Mappe e segreti non possono essere modificati se l'impostazione usa il metodo della variabile di ambiente dopo la distribuzione del pod. I criteri di sicurezza lo impediscono.
• I log di terminazione dei pod non sono supportati. Mentre i pod scrivono i log di terminazione in /dev/termination-log o in un percorso personalizzato se specificato nel manifesto del pod, l'host/kubelet non può leggere tali log. Le modifiche da guest a tale file non vengono riflesse nell'host.

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 viene specificata alcuna risorsa limits , ai carichi di lavoro non sono assegnate condivisioni CPU separate, la vCPU viene quindi condivisa con tale carico di lavoro. Se vengono specificati limiti della CPU, le condivisioni CPU vengono allocate in modo esplicito per i carichi di lavoro.
• Memoria: il gestore Kata-CC usa 2 GB di memoria per il sistema operativo UVM e X MB di memoria aggiuntiva dove X è la risorsa limits se specificata nel manifesto YAML (con conseguente vm da 2 GB quando non viene specificato alcun limite, senza memoria implicita per i contenitori). Il gestore Kata usa 256 MB di memoria di base per il sistema operativo UVM e X MB di memoria aggiuntiva quando la risorsa limits viene specificata nel manifesto YAML. Se i limiti non sono specificati, viene aggiunto un limite implicito di 1.792 MB, con conseguente aggiunta di una macchina virtuale da 2 GB e di 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 Kata ignora le richieste di risorse dal manifesto YAML del pod e, di conseguenza, il contenitore non passa le richieste allo shim. Usare la risorsa anziché la risorsa limitrequests 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

• Per informazioni sul modo in cui i carichi di lavoro e i relativi dati in un pod sono protetti, vedere la panoramica dei criteri di sicurezza dei contenitori riservati.
• Distribuire contenitori riservati nel servizio Azure Kubernetes con criteri di sicurezza predefiniti.
• 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.