Condividi tramite

Contenitori riservati (anteprima) nel servizio Azure Kubernetes (AKS)

  • Articolo

I contenitori riservati offrono un set di caratteristiche e funzionalità per proteggere ulteriormente i carichi di lavoro dei tuoi contenitori standard per raggiungere obiettivi di sicurezza dei dati, privacy dei dati e integrità del codice di runtime più elevati. Il servizio Azure Kubernetes (AKS) 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. 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.

Insieme a Pod Sandboxing, puoi eseguire carichi di lavoro sensibili isolati in Azure per proteggere i tuoi dati e carichi di lavoro. Che cosa rende un contenitore riservato:

  • 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.

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

Questo articolo ti aiuta a capire 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
  • Aggiungi un'annotazione al tuo pod YAML per contrassegnare il pod come eseguito come contenitore riservato
  • Aggiungi un criterio di sicurezza al tuo pod YAML
  • Abilita l'applicazione dei criteri di sicurezza
  • Distribuisci l'applicazione in confidential computing

Scenari supportati

I contenitori riservati (anteprima) sono adeguati agli 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.

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.
  • Gli aggiornamenti ai segreti e alle ConfigMaps non vengono riflessi nel guest.
  • I contenitori effimeri e altri metodi di risoluzione dei problemi, come execin 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 tag latest quando si specificano i contenitori.
  • Servizi, Load Balancers e EndpointSlices 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 segreti e ConfigMaps 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 vengono assegnate condivisioni CPU separate e 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 limit 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