Un workload viene creato da un autore del workload ed elabora i dati riservati con cui i collaboratori dei dati vogliono lavorare.
Un autore del workload deve assemblare le seguenti risorse per creare un workload:
Un'applicazione per elaborare i dati riservati. Puoi scrivere l'applicazione in qualsiasi lingua tu scelga, a condizione che crei un'immagine containerizzata che la supporti.
Un'immagine containerizzata in cui inserire l'applicazione utilizzando Docker.
Un repository in Artifact Registry in cui archiviare l'immagine Docker.
Policy di avvio impostate sull'immagine container che controllano la modalità di esecuzione di un workload e limitano le funzionalità di un operatore di workload dannoso.
Per eseguire il deployment del workload, una Confidential VM viene eseguita da un operatore del workload basata sull' immagine Confidential Space. In questo modo, l'immagine containerizzata viene recuperata da Artifact Registry ed eseguita.
I collaboratori dei dati devono convalidare le attestazioni di un workload prima che possa accedere ai loro dati.
Prima di iniziare
Scrivere un workload per Confidential Space non significa solo scrivere codice ed eseguire il debug. Devi anche parlare con i collaboratori dei dati per valutare le loro esigenze, configurare l'ambiente, inserire il codice in un'immagine containerizzata e collaborare con un operatore del workload per assicurarti che tutto venga eseguito correttamente.
Parla con i collaboratori dei dati
Prima di iniziare a scrivere l'applicazione, devi parlare con i collaboratori dei dati in merito ai dati privati su cui vuoi lavorare. Ecco alcune domande che puoi porre:
Quali sono gli ID organizzazione coinvolti?
Quali sono i numeri di progetto coinvolti?
A quali Google Cloud risorse devo accedere e quali sono i relativi ID e nomi?
Esistono risorse a cui devo accedere che non sono gestite da Google Cloud IAM?
Quale servizio di attestazione vuoi utilizzare: Google Cloud Attestation o Intel Trust Authority?
In che modo l'applicazione deve confrontare ed elaborare i dati privati?
Quale formato deve avere l'output?
Dove deve essere archiviato l'output e deve essere criptato?
Tutti i collaboratori dei dati vedono lo stesso risultato o gli output sono univoci per ciascuno?
Inoltre, ogni collaboratore dei dati potrebbe avere requisiti di privacy unici che devi soddisfare. È di vitale importanza che nessun dato privato venga esposto a seguito di un workload.
Crea la tua soluzione Confidential Space
È utile configurare due o più progetti con le autorizzazioni appropriate come ambiente di test, come descritto in Creare il primo ambiente Confidential Space. Cerca di rispecchiare il più possibile le configurazioni dei progetti dei collaboratori dei dati. In questo modo, puoi acquisire esperienza con le autorizzazioni tra progetti e recuperare i dati di cui hai bisogno da risorse specifiche Google Cloud . Puoi anche comprendere meglio i ruoli e le responsabilità dell'operatore del workload e del collaboratore dei dati.
Durante la fase iniziale di creazione, è utile osservare le seguenti pratiche:
Quando lavori come collaboratore dei dati, riduci al minimo la convalida dell'attestazione per velocizzare lo sviluppo.
Quando lavori come operatore del workload, utilizza l'immagine di debug di Confidential Space anziché quella di produzione quando esegui il deployment del workload. In questo modo, hai più modi per risolvere i problemi del workload.
Man mano che l'applicazione matura e il suo stato diventa più prevedibile, puoi proteggere sempre più la tua soluzione con la convalida dell'attestazione e le policy di avvioe passare all'immagine di produzione di Confidential Space.
Dopo che il workload funziona correttamente nell'ambiente di test, puoi passare al test nei progetti dei collaboratori dei dati con risorse reali, ma dati fittizi, in modo da poter mostrare ai collaboratori dei dati come funziona tutto. A questo punto, potresti iniziare a collaborare con un operatore del workload indipendente.
Quando tutto funziona e l'output è quello previsto, puoi iniziare a testare i dati di produzione. Al termine del test e dopo che tutte le parti hanno approvato i risultati, il workload è pronto per essere messo in produzione.
Fai attenzione all'output
Durante il test del codice, può essere allettante eseguire il debug stampando su STDOUT o STDERR. Se scegli di farlo, assicurati di non esporre dati privati che altre parti potrebbero leggere accedendo ai log. Prima che il codice inizi a funzionare in produzione, assicurati che non generi output diversi da quelli strettamente necessari.
Lo stesso vale per l'output finale. Fornisci solo un risultato finale che non comprometta la privacy e la sensibilità dei dati originali.
Crea un'immagine containerizzata con Docker
Le applicazioni devono essere inserite in un'immagine containerizzata creata da Docker, che viene archiviata in Artifact Registry. Quando viene eseguito il deployment di un workload, l'immagine Docker viene estratta dal repository Artifact Registry dall'immagine Confidential Space, eseguita e l'applicazione può iniziare a lavorare sulle risorse del progetto appropriate.
Quando crei l'immagine Docker, tieni presente quanto segue:
Funzionalità Linux aggiuntive
Il workload Confidential Space viene eseguito in un container Linux utilizzando containerd. Questo container viene eseguito utilizzando le funzionalità Linux predefinite.
Per aggiungere funzionalità, puoi utilizzare
tee-added-capabilities.
Limiti di disco e memoria
Confidential Space ridimensiona automaticamente la partizione con stato del disco di avvio quando si utilizzano dimensioni del disco di avvio più grandi. La dimensione della partizione è approssimativamente la dimensione del disco di avvio meno 5 GB.
Nell'ambito delle protezioni del file system di integrità di Confidential Space, Confidential Space archivia i tag di integrità del disco in memoria. Questo utilizza circa l'1% di overhead di memoria per ogni byte del disco. Ad esempio, un disco da 100 GB richiede 1 GB di memoria e un disco da 10 TB richiede 100 GB di memoria.
Assicurati di rispettare i limiti di memoria della VM. La memoria di swap è disabilitata sulle VM Confidential Space, il che significa che un utilizzo eccessivo della memoria può causare l'arresto anomalo del workload. Verifica che la selezione della macchina supporti la memoria utilizzata dal workload oltre all'overhead di integrità del disco.
Arresti controllati
Quando un operatore richiede l'arresto di una VM Confidential Space, Confidential Space Launcher tenta di arrestare normalmente il workload inviando un segnale SIGTERM. Al momento della ricezione, il workload ha fino a 120 secondi per eseguire la pulizia prima che Confidential Space Launcher avvii il processo di arresto. I workload che non implementano la gestione dei segnali SIGTERM terminano immediatamente alla ricezione del segnale.
Montaggi di scratch in memoria
Confidential Space supporta l'aggiunta di spazi di scratch in memoria. Questo utilizza la memoria disponibile nella VM Confidential Space. Poiché lo spazio di scratch utilizza la memoria della Confidential VM, ha le stesse proprietà di integrità e riservatezza della Confidential VM.
Puoi utilizzare
tee-dev-shm-size
per aumentare le dimensioni del montaggio della memoria condivisa /dev/shm per il workload.
Le dimensioni di /dev/shm sono specificate in KB.
Puoi utilizzare
tee-mount per specificare
i montaggi tmpfs nel container in esecuzione utilizzando configurazioni separate da punti e virgola.
type e source sono sempre tmpfs. The destination è il punto di montaggio,
che interagisce con la
tee.launch_policy.allow_mount_destinations policy di avvio. Puoi specificare facoltativamente le dimensioni di tmpfs in byte. La dimensione predefinita è il 50% della memoria della VM.
Porte in entrata
Per impostazione predefinita, le VM Confidential Space operano con una regola firewall per bloccare tutte le porte in entrata. Quando utilizzi una versione dell'immagine Confidential Space 230600 o successive, puoi specificare le porte in entrata da mantenere aperte nel Dockerfile durante la creazione dell'immagine del workload.
Per aprire le porte, aggiungi la parola chiave EXPOSE al Dockerfile, insieme al numero di porta da mantenere aperto e a un protocollo facoltativo tcp o udp. Se non specifichi il protocollo per una porta, sono consentiti sia TCP che UDP. Ecco un esempio di Dockerfile che espone le porte in entrata:
FROM alpine:latest
EXPOSE 80
EXPOSE 443/tcp
EXPOSE 81/udp
WORKDIR /test
COPY salary /test
ENTRYPOINT ["/test/salary"]
CMD []
A seconda dell'immagine di base utilizzata, alcune porte potrebbero essere già esposte. Il Dockerfile espone solo porte aggiuntive; non può bloccare le porte già aperte dall'immagine di base.
Gli operatori del workload devono assicurarsi che le porte esposte siano aperte nel loro firewall VPC prima di eseguire il workload. I numeri di porta possono essere forniti dall'autore del workload o estratti dalle informazioni dell'immagine Docker.
Le porte esposte vengono registrate nella console e reindirizzate a Cloud Logging
quando si utilizza la
tee-container-log-redirect
variabile di metadati.
Policy di avvio
Le policy di avvio sostituiscono le variabili di metadati della VM impostate dagli operatori del workload per limitare le azioni dannose. Un autore del workload può impostare le policy con un'etichetta durante la creazione dell'immagine container.
Ad esempio, in un Dockerfile:
LABEL "tee.launch_policy.allow_cmd_override"="true"
In un file BUILD di Bazel:
container_image(
...
labels={"tee.launch_policy.allow_cmd_override":"true"}
...
)
Le policy di avvio disponibili sono riportate nella tabella seguente:
| Norme | Tipo | Descrizione |
|---|---|---|
|
Interagisce con:
|
Booleano (il valore predefinito è false) |
Determina se l'operatore del workload può aggiungere funzionalità Linux aggiuntive al container del workload. |
|
Interagisce con:
|
Booleano (il valore predefinito è false) |
Determina se il container del workload può includere un montaggio di cgroup con spazio dei nomi in /sys/fs/cgroup.
|
|
Interagisce con:
|
Booleano (il valore predefinito è false) |
Determina se il
CMD
specificato nel Dockerfile del container del workload può essere
sostituito da un operatore del workload con il valore di metadati
tee-cmd.
|
|
Interagisce con:
|
Stringa separata da virgole |
Una stringa separata da virgole di nomi di variabile di ambiente consentiti che
possono essere impostati da un operatore del workload con
tee-env-ENVIRONMENT_VARIABLE_NAME
valori di metadati.
|
|
Interagisce con: |
Stringa separata da due punti |
Una stringa separata da due punti di directory di montaggio consentite a cui l'operatore del workload
può eseguire il montaggio utilizzando Ad esempio: |
|
Interagisce con:
|
Stringa definita |
Determina il funzionamento della registrazione se
I valori validi sono i seguenti:
|
|
Interagisce con:
|
Stringa definita |
Determina il funzionamento del monitoraggio dell'utilizzo della memoria del workload se
I valori validi sono i seguenti:
|
Più esecuzioni di workload
Per eseguire di nuovo un workload, l'operatore del workload deve riavviare l'istanza VM. In questo modo, il workload viene avviato nell'ambiente più pulito possibile e il disco dell'istanza VM viene criptato con una nuova chiave effimera.
Il riavvio risolve il vettore d'attacco della modifica di un'immagine del workload sul disco dopo che è stata scaricata e misurata. Tuttavia, aggiunge anche overhead come il tempo di avvio e l'inserimento dell'immagine del workload in ogni esecuzione del workload. Se questi overhead influiscono troppo sulle prestazioni del workload, a costo di aumentare il profilo di rischio, puoi codificare un riavvio del workload nel workload stesso.
Cgroup con spazio dei nomi
Per impostazione predefinita, il workload Confidential Space viene eseguito senza un montaggio di cgroup per impostazione predefinita.
Per gestire i cgroup all'interno del container del workload, puoi utilizzare
tee-cgroup-ns. Questa chiave di metadati indica all'istanza VM di creare un montaggio in /sys/fs/cgroup nel file system del container.
Immagini container riproducibili
La creazione di un'immagine container in modo riproducibile può contribuire ad aumentare la fiducia tra le parti. Puoi creare immagini riproducibili con Bazel.
Risorse non gestite da Google Cloud IAM
Per accedere alle risorse non gestite da Google Cloud IAM, il workload deve specificare un segmento di pubblico personalizzato.
Per ulteriori informazioni, consulta Accedere alle risorse non gestite da Google Cloud IAM.
Immagini container firmate
Puoi firmare un'immagine container con una chiave pubblica, che un collaboratore dei dati può quindi utilizzare per l'attestazione anziché specificare un digest dell'immagine nella sua policy WIP.
Ciò significa che i collaboratori dei dati non devono aggiornare le policy WIP ogni volta che viene aggiornato un workload e il workload può continuare ad accedere alle risorse protette senza interruzioni.
Puoi utilizzare Sigstore Cosign per
firmare l'immagine container. Affinché Confidential Space recuperi le firme, gli operatori del workload
devono aggiungere le informazioni sulla firma alla
tee-signed-image-repos
variabile di metadati prima di eseguire il deployment del workload.
Durante il runtime, le firme vengono inviate a un servizio di attestazione per la verifica. Il servizio di attestazione restituisce un token di attestazione che contiene le attestazioni di firma verificate. Ecco un esempio di attestazione di firma:
"image_signatures": [
{
"key_id": "hexadecimal-sha256-fingerprint-public-key1",
"signature": "base64-encoded-signature",
"signature_algorithm": "RSASSA_PSS_SHA256"
},
{
"key_id": "hexadecimal-sha256-fingerprint-public-key2",
"signature": "base64-encoded-signature",
"signature_algorithm": "RSASSA_PSS_SHA256",
},
{
"key_id": "hexadecimal-sha256-fingerprint-public-key3",
"signature": "base64-encoded-signature",
"signature_algorithm": "RSASSA_PSS_SHA256",
}
]
Per configurare la firma dell'immagine container, consulta Codelab sull'immagine container firmata.