Plug-in di confidential computing per le macchine virtuali riservate
Il servizio Azure Kubernetes offre un plug-in per le macchine virtuali di confidential computing di Azure. Il plug-in, confcom, è un set di daemon. Il plug-in può essere eseguito solo per le macchine virtuali riservate Intel SGX (Software Guard Extensions) in un cluster del servizio Azure Kubernetes. Questo plug-in viene registrato a livello di cluster del servizio Azure Kubernetes. È possibile usare il plug-in per gestire facilmente i nodi riservati. Abilitare il plug-in nel cluster del servizio Azure Kubernetes prima di iniziare.
Plug-in del dispositivo Intel SGX per il servizio Azure Kubernetes
Il plug-in del dispositivo SGX implementa l'interfaccia del plug-in del dispositivo Kubernetes per la memoria EPC (Enclave Page Cache). In effetti, con questo plug-in la memoria EPC diventa un altro tipo di risorsa in Kubernetes. Gli utenti possono specificare dei limiti per la memoria EPC esattamente come per altre risorse. Oltre alla funzione di pianificazione, il plug-in del dispositivo consente di assegnare le autorizzazioni di driver di dispositivo SGX ai contenitori di carichi di lavoro riservati. È disponibile un'implementazione di esempio della distribuzione basata sulla memoria EPC (kubernetes.azure.com/sgx_epc_mem_in_MiB).
PSW con helper di Quote SGX
Le applicazioni dell'enclave che eseguono l'attestazione remota devono generare una Quote. La Quote fornisce la prova crittografica dell'identità e dello stato dell'applicazione, insieme all'ambiente host dell'enclave. La generazione di Quote si basa su alcuni componenti software attendibili di Intel, che fanno parte dei componenti software della piattaforma SGX (PSW/DCAP). Questo PSW viene fornito come DaemonSet che viene eseguito per nodo. È possibile usare PSW per richiedere la Quote dell'attestazione dalle app enclave. L'uso del servizio Azure Kubernetes consente di gestire meglio la compatibilità tra il componente PSW e altri componenti SW nell'host. Leggere i dettagli della funzionalità di seguito.
Le applicazioni dell'enclave che eseguono l'attestazione remota richiedono una Quote generata. Questa Quote fornisce la prova crittografica dell'identità, dello stato e dell'ambiente in esecuzione dell'applicazione. Per la generazione sono richiesti componenti software attendibili che fanno parte della piattaforma PSW Intel.
Panoramica
Nota
Questa funzionalità è necessaria solo per le macchine virtuali DCsv2/DCsv3 che usano hardware Intel SGX specializzato.
Intel supporta due modalità di attestazione per l'esecuzione della generazione di Quote. Per informazioni su come scegliere il tipo, vedere [differenze tra i tipi di attestazione] (#attestation-type-differences).
In-process: ospita i componenti software attendibili all'interno del processo dell'applicazione enclave. Questo metodo è utile quando si esegue l'attestazione locale (tra 2 app enclave in un singolo nodo della macchina virtuale)
out-of-process: ospita i componenti software attendibili all'esterno dell'applicazione enclave. Si tratta di un metodo preferito per l'esecuzione dell'attestazione remota.
Per impostazione predefinita, le applicazioni SGX create con Open Enclave SDK usano la modalità di attestazione in-process. Le applicazioni basate su SGX consentono l'out-of-process e richiedono hosting aggiuntivo. Queste applicazioni espongono i componenti necessari, ad esempio AESM (Architecture Enclave Service Manager), esterni all'applicazione.
L'uso di questa funzionalità è altamente consigliato. Questa funzionalità migliora il tempo di attività delle app enclave durante gli aggiornamenti della piattaforma Intel o del driver DCAP.
Differenze tra i tipi di attestazione
Non sono necessari aggiornamenti per i componenti di generazione delle Quote di PSW per ogni applicazione in contenitori.
la modalità out-of-process evita ai proprietari di contenitori la necessità di gestire gli aggiornamenti all'interno del contenitore. I proprietari di contenitori usano invece l'interfaccia fornita che richiama il servizio centralizzato all'esterno del contenitore.
Per l'out-of-process non occorre preoccuparsi degli errori causati da componenti PSW non aggiornati. la generazione delle citazioni coinvolge i componenti software attendibili Quoting Enclave (QE) e Provisioning Certificate Enclave (PCE), che fanno parte della Trusted Computing Base (TCB). Questi componenti software devono essere aggiornati per poter gestire i requisiti di attestazione. Il provider gestisce gli aggiornamenti di questi componenti. I clienti non devono mai occuparsi degli errori di attestazione causati da componenti SW non aggiornati all'interno del contenitore.
La modalità out-of-process usa meglio la memoria EPC. Nella modalità di attestazione in-process ogni applicazione dell'enclave deve creare un'istanza della copia di QE e PCE per l'attestazione remota. Con la modalità out-of-process, il contenitore non ospita tali enclavi, pertanto non viene utilizzata la memoria dell'enclave dalla quota del contenitore.
Esistono anche misure di sicurezza contro l'applicazione del kernel. Quando il driver SGX viene trasmesso al kernel Linux, un'enclave ha privilegi più elevati. Questi privilegi consentono all'enclave di richiamare PCE, che interrompe l'applicazione enclave in esecuzione in modalità in-process. Per impostazione predefinita, le enclave non ottengono questa autorizzazione. Per concedere questo privilegio a un'applicazione enclave è necessario modificare il processo di installazione dell'applicazione. Il provider del servizio che gestisce le richieste out-of-process verifica che il servizio sia installato con questi privilegi.
Non è necessario controllare la compatibilità con le versioni precedenti di PSW e DCAP. Il provider convalida la compatibilità con le versioni precedenti degli aggiornamenti dei componenti di generazione delle Quote della piattaforma PSW. Questo passaggio gestisce i problemi di compatibilità e li risolve prima di distribuire gli aggiornamenti per i carichi di lavoro riservati.
Attestazione out-of-process per carichi di lavoro riservati
Il modello di attestazione out-of-process funziona per i carichi di lavoro riservati. Il richiedente della Quote e la generazione della Quote vengono eseguiti separatamente, ma nello stesso computer fisico. La generazione della Quote viene eseguita in modo centralizzato e serve le richieste di QUOTE di tutte le entità. Occorre definire in modo corretto l'interfaccia e renderla individuabile per consentire a qualsiasi entità di richiedere Quote.
Il modello astratto si applica agli scenari di carichi di lavoro riservati. Questo modello usa il servizio AESM già disponibile. Il servizio AESM è inserito in un contenitore e viene distribuito come set di daemon nel cluster Kubernetes. Kubernetes garantisce che una singola istanza di un contenitore del servizio AESM, di cui viene eseguito il wrapping in un pod, venga distribuita in ogni nodo dell'agente. Il nuovo set di daemon delle Quote SGX ha una dipendenza dal set di daemon sgx-device-plugin, poiché il contenitore del servizio AESM dovrebbe richiedere memoria EPC a sgx-device-plugin per avviare le enclavi QE e PCE.
Ogni contenitore deve acconsentire esplicitamente all'uso della generazione di Quote out-of-process impostando la variabile di ambiente SGX_AESM_ADDR=1 durante la creazione. Il contenitore deve anche includere il pacchetto libsgx-quote-ex, che indirizza la richiesta al socket di dominio Unix predefinito
Un'applicazione può comunque usare l'attestazione in-process come prima. Tuttavia, non è possibile usare contemporaneamente sia la modalità in-process che out-of-process all'interno di un'applicazione. L'infrastruttura out-of-process è disponibile per impostazione predefinita e utilizza risorse.
Nota
Se si usa un software wrapper Intel SGX (OSS/ISV) per eseguire i contenitori non modificati, l'interazione di attestazione con l'hardware viene in genere gestita per le app di livello superiore. Fare riferimento all'implementazione dell'attestazione per ogni provider.
Implementazione di esempio
Per impostazione predefinita, questo servizio non è abilitato per il cluster del servizio Azure Kubernetes con il componente aggiuntivo "confcom". Aggiornare il componente aggiuntivo con il comando seguente
az aks addon update --addon confcom --name " YourAKSClusterName " --resource-group "YourResourceGroup " --enable-sgxquotehelper
Quando il servizio è in esecuzione, usare l'esempio docker seguente per un'applicazione basata su Open Enclave per convalidare il flusso. Impostare la variabile di ambiente SGX_AESM_ADDR=1 nel file Docker. Oppure impostare la variabile nel file di distribuzione. Seguire questo esempio per i dettagli del file Docker e del file YAML di distribuzione.
Nota
Per il corretto funzionamento dell'attestazione out-of-process, il pacchetto libsgx-quote-ex di Intel deve essere incluso nel contenitore dell'applicazione. Le istruzioni riportate di seguito contengono i dettagli.
# Refer to Intel_SGX_Installation_Guide_Linux for detail
FROM ubuntu:18.04 as sgx_base
RUN apt-get update && apt-get install -y \
wget \
gnupg
# Add the repository to sources, and add the key to the list of
# trusted keys used by the apt to authenticate packages
RUN echo "deb [arch=amd64] https://download.01.org/intel-sgx/sgx_repo/ubuntu bionic main" | tee /etc/apt/sources.list.d/intel-sgx.list \
&& wget -qO - https://download.01.org/intel-sgx/sgx_repo/ubuntu/intel-sgx-deb.key | apt-key add -
# Add Microsoft repo for az-dcap-client
RUN echo "deb [arch=amd64] https://packages.microsoft.com/ubuntu/18.04/prod bionic main" | tee /etc/apt/sources.list.d/msprod.list \
&& wget -qO - https://packages.microsoft.com/keys/microsoft.asc | apt-key add -
FROM sgx_base as sgx_sample
RUN apt-get update && apt-get install -y \
clang-7 \
libssl-dev \
gdb \
libprotobuf10 \
libsgx-dcap-ql \
libsgx-quote-ex \
az-dcap-client \
open-enclave
WORKDIR /opt/openenclave/share/openenclave/samples/attestation
RUN . /opt/openenclave/share/openenclave/openenclaverc \
&& make build
# this sets the flag for out of proc attestation mode, alternatively you can set this flag on the deployment files
ENV SGX_AESM_ADDR=1
CMD make run
Impostare invece la modalità di attestazione out-of-process nel file YAML di distribuzione, come illustrato di seguito:
apiVersion: batch/v1
kind: Job
metadata:
name: sgx-test
spec:
template:
spec:
containers:
- name: sgxtest
image: <registry>/<repository>:<version>
env:
- name: SGX_AESM_ADDR
value: 1
resources:
limits:
kubernetes.azure.com/sgx_epc_mem_in_MiB: 10
volumeMounts:
- name: var-run-aesmd
mountPath: /var/run/aesmd
restartPolicy: "Never"
volumes:
- name: var-run-aesmd
hostPath:
path: /var/run/aesmd
La distribuzione dovrebbe avere esito positivo e consentire alle app di eseguire l'attestazione remota usando il servizio helper Quote SGX.