Criteri di sicurezza per contenitori riservati sul servizio Azure Kubernetes

Come descritto dal CCC (Confidential Computing Consortium), “Il Confidential Computing è la protezione dei dati in uso eseguendo calcoli in un ambiente di esecuzione attendibile (TEE) attestato e basato su hardware." I contenitori riservati del servizio Azure Kubernetes sono progettati per proteggere i dati dei pod Kubernetes in uso da accessi non autorizzati dall'esterno di questi pod. Ogni pod viene eseguito in una macchina virtuale riservata (CVM) protetta dal TEE AMD SEV-SNP crittografando i dati in uso e impedendo l'accesso ai dati da parte del sistema operativo (OS) host. I tecnici Microsoft hanno collaborato con le community open source dicontenitori riservati (CoCo) e contenitori Kata alla progettazione e all'implementazione dei contenitori riservati.

Panoramica dei criteri di sicurezza

Uno dei componenti principali dell'architettura di sistema dei contenitori Kata è l'agente Kata. Quando si utilizzano contenitori Kata per implementare contenitori riservati, l'agente viene eseguito all'interno del TEE basato su hardware e quindi fa parte della TCB (Trusted Computing Base) del pod. Come illustrato nel diagramma seguente, l'agente Kata fornisce un set di API ttrpc che consentono ai componenti di sistema esterni al TEE di creare e gestire pod Kubernetes basati su CVM. Questi altri componenti (ad esempio Kata Shim) non fanno parte della TCB del pod. Pertanto, l'agente deve proteggersi da chiamate API di sistema potenzialmente contenenti bug o dannose.

Nei contenitori riservati del servizio Azure Kubernetes, l'autoprotezione dell'API dell'agente Kata viene implementata usando criteri di sicurezza (noti anche come Criteri dell'agente Kata), specificati dai proprietari dei pod riservati. Il documento sui criteri contiene regole e dati corrispondenti a ciascun pod, usando il linguaggio dei criteri Rego standard del settore. L'applicazione dei criteri all'interno della CVM viene implementata usando l'OPA (Open Policy Agent), un progetto graduale della CNF (Cloud Native Computing Foundation).

Contenuti dei criteri

I criteri di sicurezza descrivono tutte le chiamate alle API ttrpc dell'agente (e i parametri di queste chiamate API) previste per la creazione e la gestione del pod riservato. Il documento sui criteri di ogni pod è un file di testo che usa il linguaggio Rego. Sono disponibili tre sezioni generali del documento sui criteri.

Dati

I dati dei criteri sono specifici per ciascun pod e contengono, ad esempio:

• Un elenco di contenitori che si prevede venga creato nel pod.
• Un elenco di API bloccate dai criteri per impostazione predefinita (per motivi di riservatezza).

Esempi di dati inclusi nel documento sui criteri per ciascuno dei contenitori in un pod:

• Informazioni sull'integrità dell'immagine.
• Comandi eseguiti nel contenitore.
• Volumi di archiviazione e montaggi.
• Contesto di protezione dell'esecuzione. Ad esempio, indicazione se il file system radice è di sola lettura.
• Indicazione se il processo è autorizzato a ottenere nuovi privilegi.
• variabili di ambiente.
• Altri campi della configurazione del runtime del contenitore OCI (Open Container Initiative).

Regole

Le regole dei criteri, specificate nel formato Rego, vengono eseguite dall'OPA per ogni chiamata API dell'agente Kata dall'esterno della CVM. L'agente fornisce tutti gli input dell'API all'OPA e l'OPA utilizza le regole per verificare se gli input sono coerenti con i dati dei criteri. Se le regole e i dati dei criteri non consentono input dell'API, l'agente rifiuta la chiamata API restituendo un messaggio di errore “bloccato dai criteri". Di seguito sono riportati alcuni esempi di regole:

• Ogni livello del contenitore viene esposto come dispositivo di blocco virtio di sola lettura alla CVM. L'integrità di questi dispositivi di blocco è protetta utilizzando la tecnologia dm-verity del kernel Linux. Il valore radice previsto dell'albero hash dm-verity è incluso nei dati dei criteri e verificato a runtime dalle regole dei criteri.
• Le regole rifiutano la creazione di contenitori quando viene rilevata una riga di comando, il montaggio di una risorsa di archiviazione, un contesto di protezione dell'esecuzione o una variabile di ambiente imprevista.

Per impostazione predefinita, le regole dei criteri sono comuni a tutti i pod. Lo strumento genpolicy genera i dati dei criteri ed è specifico per ciascun pod.

Valori predefiniti

Quando si valutano le regole Rego utilizzando i dati dei criteri e gli input dell'API come parametri, l'OPA tenta di trovare almeno un set di regole che restituisca un valore true in base ai dati di input. Se le regole non restituiscono true, l'OPA restituisce all'agente il valore predefinito per quell'API. Esempi di valori predefiniti dei criteri:

• default CreateContainerRequest := false: significa che qualsiasi chiamata all'API CreateContainer viene rifiutata a meno che un set di regole di criteri non consenta esplicitamente tale chiamata.

• default GuestDetailsRequest := true: significa che le chiamate dall'esterno del TEE all'API GuestDetails sono sempre consentite perché i dati restituiti da questa API non sono sensibili per la riservatezza dei carichi di lavoro del cliente.

Invio del criterio all'agente Kata

Tutte le CVM dei contenitori riservati del servizio Azure Kubernetes vengono avviate usando un criterio generico e predefinito incluso nel file system radice delle CVM. Pertanto, è necessario fornire all'agente in fase di esecuzione un criterio che corrisponda al carico di lavoro effettivo del cliente. Il testo del criterio è incorporato nel file manifesto YAML come descritto in precedenza e viene fornito in questo modo all'agente nelle prime fasi dell'inizializzazione della CVM. L'annotazione dei criteri passa attraverso i componenti kubelet, containerd e Kata shim del sistema di contenitori riservati del servizio Azure Kubernetes. Quindi l'agente che collabora con l'OPA applica il criterio per tutte le chiamate alle proprie API.

Il criterio viene fornito utilizzando componenti che non fanno parte della TCB, quindi inizialmente questo criterio non è attendibile. L'attendibilità del criterio deve essere stabilita tramite attestazione remota, come descritto nella sezione seguente.

Stabilire l'attendibilità nel documento dei criteri

Prima di creare la CVM del POD, il Kata shim calcola l'hash SHA256 del documento dei criteri e attribuisce tale valore hash al TEE. Questa azione crea una forte associazione tra i contenuti del criterio e la CVM. Questo campo TEE non è modificabile successivamente né dal software eseguito all'interno della CVM, né all'esterno di essa.

Dopo aver ricevuto il criterio, l'agente verifica che l'hash del criterio corrisponda al campo TEE non modificabile. L'agente rifiuta il criterio in ingresso se rileva una mancata corrispondenza dell'hash.

Prima di gestire informazioni sensibili, i carichi di lavoro devono eseguire passaggi di attestazione remota per dimostrare a qualsiasi relying party che il carico di lavoro viene eseguito usando le versioni previste di TEE, sistema operativo, agente, OPA e versioni del file system radice. L'attestazione è implementata in un contenitore in esecuzione all'interno della CVM che ottiene un'evidenza di attestazione firmata dall'hardware AMD SEV-SNP. Uno dei campi dell'evidenza di attestazione è il campo TEE dell'hash del criterio descritto in precedenza. Pertanto, il servizio di attestazione può verificare l'integrità del criterio confrontando il valore di questo campo con l'hash previsto del criterio del pod.

Applicazione dei criteri

L'agente Kata è responsabile dell'applicazione dei criteri. Microsoft ha fornito alla community Kata e CoCo il codice dell'agente responsabile del controllo dei criteri per ogni chiamata API ttrpc dell'agente. Prima di eseguire le azioni corrispondenti all'API, l'agente utilizza l'API REST dell'OPA per verificare se le regole e i dati dei criteri consentono o bloccano la chiamata.

Passaggi successivi

Distribuire un contenitore riservato nel servizio Azure Kubernetes