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 la capacità di un operatore di workload dannoso.
Per eseguire il deployment del workload, un operenziale VM viene eseguito da un operatore di workload basato 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 di 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?
Quali sono le Google Cloud risorse a cui devo accedere e quali sono i loro ID e nomi?
Esistono risorse a cui devo accedere che non sono gestite da Google Cloud IAM?
In che modo l'applicazione deve confrontare ed elaborare i dati privati?
In che formato deve essere 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 replicare 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 di 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 di 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 di 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 utilizzi 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. Assicurati che la selezione della macchina supporti la memoria utilizzata dal workload oltre all'overhead di integrità del disco.
Token OIDC scaduti
Quando il workload viene avviato, viene reso disponibile un token OIDC. Contiene attestazioni di attestazione verificate sulla VM del workload e viene archiviato nel container del workload in /run/container_launcher/attestation_verifier_claims_token. Il token scade dopo 60 minuti.
Se il token scade, viene tentato un aggiornamento in background utilizzando il backoff esponenziale fino a quando non va a buon fine. Se un aggiornamento non riesce (a causa di problemi di rete, un'interruzione del servizio di attestazione o altro), il codice del workload deve essere in grado di gestire l'errore.
Il workload potrebbe gestire un errore di aggiornamento del token in uno dei seguenti modi:
Ignora il token scaduto, supponendo che non sia più necessario dopo l'utilizzo iniziale.
Attendi che il token scaduto venga aggiornato correttamente.
Esci dal workload.
Montaggi di scratch in memoria
Confidential Space supporta l'aggiunta di spazi di scratch in memoria. 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.
La dimensione di /dev/shm è specificata 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. Facoltativamente, puoi specificare 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 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:
|
Esecuzioni multiple di workload
Per garantire un ambiente pulito, è necessario riavviare una VM per riavviare un workload. In questo modo, il disco della VM viene criptato con una chiave effimera, per risolvere il vettore d'attacco della modifica di un'immagine del workload sul disco dopo che è stata scaricata e misurata.
Inoltre, vengono aggiunti overhead come il tempo di avvio e l'estrazione dell'immagine del workload a ogni esecuzione del workload. Se questi overhead influiscono troppo sulle prestazioni del workload, puoi codificare un riavvio del workload nel workload stesso, a costo di aumentare il profilo di rischio.
Cgroup con spazio dei nomi
Per impostazione predefinita, il workload Confidential Space viene eseguito senza un montaggio cgroup.
Per gestire i cgroup all'interno del container del workload, puoi utilizzare
tee-cgroup-ns. In questo modo, viene creato 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. Per assicurarsi che Confidential Space possa recuperare 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 al servizio di attestazione di Confidential Space 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.