Un workload viene creato da un autore di workload ed elabora i dati confidenziali con cui i collaboratori dei dati vogliono lavorare.
L'autore di un carico di lavoro deve assemblare le seguenti risorse per creare un carico di lavoro:
Un'applicazione per elaborare i dati riservati. Puoi scrivere la tua applicazione in qualsiasi lingua tu scelga, a condizione che crei un'immagine containerizzata che la supporti.
Un'immagine containerizzata per pacchettizzare l'applicazione utilizzando Docker.
Un repository in Artifact Registry per archiviare l'immagine Docker.
Criteri di avvio impostati 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 operatore del workload esegue una Confidential VM in base all'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 di poter accedere ai propri 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, impacchettare il codice in un'immagine containerizzata e collaborare con un operatore del carico di lavoro per assicurarti che tutto venga implementato correttamente.
Parlare con i collaboratori dei dati
Prima di iniziare a scrivere l'applicazione, devi parlare con i tuoi collaboratori dei 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?
Come deve confrontare ed elaborare i dati privati l'applicazione?
In che formato deve essere l'output?
Dove deve essere archiviato l'output e deve essere criptato?
Tutti i collaboratori ai dati vedono lo stesso risultato o gli output sono unici per ciascuno?
Inoltre, ogni collaboratore dei dati potrebbe avere requisiti di privacy unici che devi soddisfare. È fondamentale 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 in Creare il primo ambiente Confidential Space. Cerca di replicare al meglio 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 Google Cloud specifiche. Puoi anche farti un'idea dei ruoli di operatore del workload e collaboratore dei dati e delle loro responsabilità.
Durante la fase iniziale di creazione, è utile osservare le seguenti pratiche:
Quando lavori come collaboratore di dati, mantieni la convalida dell'attestazione al minimo per velocizzare lo sviluppo.
Quando lavori come operatore del workload, utilizza l'immagine di debug di Confidential Space anziché la produzione quando esegui il deployment del workload. In questo modo, hai più modi per risolvere i problemi relativi al carico di lavoro.
Man mano che la tua applicazione matura e il suo stato diventa più prevedibile, puoi proteggere sempre più la tua soluzione con la convalida dell'attestazione e le norme di lancio e passare all'immagine di produzione di Confidential Space.
Dopo aver verificato il corretto funzionamento del carico di lavoro nell'ambiente di test, puoi passare ai test nei progetti dei collaboratori dei dati con risorse reali, ma dati falsi, in modo da poter dimostrare ai collaboratori dei dati come funziona tutto. A questo punto, potresti iniziare a lavorare con un operatore di workload indipendente.
Quando tutto funziona e l'output è quello previsto, puoi iniziare a eseguire i test sui dati di produzione. Una volta completati i test e ottenuta l'approvazione di tutte le parti interessate, 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, fai attenzione a non esporre dati privati
che altre parti potrebbero leggere accedendo ai log. Prima che il codice inizi
a funzionare in produzione, assicurati che non restituisca altro
se non ciò che è strettamente necessario.
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 pacchettizzate 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 stateful 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 per l'integrità di Confidential Space, Confidential Space memorizza i tag di integrità del disco in memoria. Questo utilizza un overhead di memoria di circa l'1% 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 è disattivata 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 l'utilizzo della memoria del workload oltre al sovraccarico di integrità del disco.
Token OIDC scaduti
All'avvio, un token OIDC viene reso disponibile per l'utilizzo da parte del carico di lavoro. Contiene
attestazioni verificate sulla VM del workload ed è 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 finché 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 tuo 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 l'aggiornamento del token scaduto.
Esci dal workload.
Montaggi scratch in memoria
Confidential Space supporta l'aggiunta di spazi di lavoro temporanei in memoria. Viene utilizzata la memoria disponibile nella VM Confidential Space. Poiché lo spazio di lavoro 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 punto di montaggio della memoria condivisa /dev/shm per il workload.
La dimensione /dev/shm è specificata in kB.
Puoi utilizzare
tee-mount per specificare
i montaggi tmpfs nel container in esecuzione utilizzando configurazioni
separate da punto e virgola. type e source sono sempre tmpfs. destination è
il punto di montaggio, che interagisce con le
norme di avvio di tee.launch_policy.allow_mount_destinations. Se vuoi, puoi
specificare la dimensione 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 di Confidential Space 230600 o successive,
puoi specificare le porte in entrata da mantenere aperte in Dockerfile durante la creazione
dell'immagine del carico di lavoro.
Per aprire le porte, aggiungi la parola chiave EXPOSE al tuo Dockerfile, insieme al
numero di porta da mantenere aperta 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 tuo
Dockerfile espone solo porte aggiuntive; non può bloccare porte che sono
già state aperte dall'immagine di base.
Gli operatori del workload devono assicurarsi che le porte esposte siano aperte nel firewall VPC prima di eseguire il workload. I numeri di porta possono essere forniti dall'autore del workload o estratti dalle informazioni sull'immagine Docker.
Le porte esposte vengono registrate nella console e reindirizzate a Cloud Logging
quando viene utilizzata la variabile di metadati tee-container-log-redirect.
Norme di lancio
I criteri di avvio sostituiscono le variabili dei metadati VM impostate dagli operatori dei workload per limitare le azioni dannose. L'autore di un workload può impostare criteri 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 norme di lancio disponibili sono riportate nella tabella seguente:
| Norme | Tipo | Descrizione |
|---|---|---|
|
Interazione con:
|
Booleano (il valore predefinito è false) |
Determina se l'operatore del carico di lavoro può aggiungere funzionalità Linux aggiuntive al container del carico di lavoro. |
|
Interazione 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.
|
|
Interazione con:
|
Booleano (il valore predefinito è false) |
Determina se il valore di
CMD
specificato in Dockerfile del container del carico di lavoro può essere
ignorato da un operatore del carico di lavoro con il valore dei metadati
tee-cmd.
|
|
Interazione 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 dei metadati.
|
|
Interazione con:
|
Stringa separata da due punti |
Una stringa separata da due punti di directory di montaggio consentite che l'operatore del workload può montare utilizzando Ad esempio: |
|
Interazione con:
|
Stringa definita |
Determina il funzionamento della registrazione se
I valori validi sono:
|
|
Interazione con:
|
Stringa definita |
Determina il funzionamento del monitoraggio dell'utilizzo della memoria del workload se
I valori validi sono:
|
Più esecuzioni del carico di lavoro
Per garantire un ambiente pulito, una VM deve essere riavviata per riavviare un workload. In questo modo il disco della VM viene criptato con una chiave effimera, per contrastare il vettore di attacco della modifica di un'immagine del workload sul disco dopo il download e la misurazione.
Inoltre, aggiunge overhead come il tempo di avvio e il pull dell'immagine del workload a ogni esecuzione del workload. Se questi overhead influiscono troppo sulle prestazioni del tuo workload, puoi codificare un riavvio del workload nel workload stesso, a costo di aumentare il tuo 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 carico di lavoro, puoi utilizzare tee-cgroup-ns. In questo modo verrà creato un punto di 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 tuo workload deve specificare un pubblico personalizzato.
Per maggiori informazioni, vedi 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ò poi utilizzare per l'attestazione anziché specificare un digest dell'immagine nel proprio criterio WIP.
Ciò significa che i collaboratori dei dati non devono aggiornare i criteri 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 garantire che Confidential Space possa recuperare le
firme, gli operatori dei carichi di lavoro devono aggiungere le informazioni sulla firma alla
variabile di metadati tee-signed-image-repos prima di eseguire il deployment del carico di lavoro.
Durante il runtime, le firme vengono inviate al servizio di attestazione Confidential Space per la verifica. Il servizio di attestazione restituisce un token di rivendicazioni di attestazione che contiene le rivendicazioni di firma verificate. Ecco un esempio di rivendicazione della 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 delle immagini container, consulta il codelab Immagine container firmata.