Un workload viene creato da un autore e tratta i dati confidenziali con cui i collaboratori dei dati vogliono lavorare.
Un autore di carichi di lavoro deve mettere insieme le seguenti risorse per creare un carico di lavoro:
Un'applicazione per l'elaborazione dei dati riservati. Puoi scrivere la tua applicazione in qualsiasi lingua, a condizione che tu crei un'immagine container che la supporti.
Un'immagine containerizzata in cui pacchettizzare l'applicazione utilizzando Docker.
Un repository in Artifact Registry in cui archiviare l'immagine Docker.
Criteri di lancio impostati sull'immagine del contenitore che controllano la modalità di esecuzione di un carico di lavoro e limitano la funzionalità di un operatore di carico di lavoro malintenzionato.
Per eseguire il deployment del carico di lavoro, un operatore del carico di lavoro esegue una VM Confidential in base all'immagine Confidential Space. L'immagine containerizzata viene recuperata da Artifact Registry ed eseguita.
I collaboratori dei dati devono convalidare le attestazioni di un carico di lavoro prima che possa accedere ai loro dati.
Prima di iniziare
La scrittura di un workload per Confidential Space non si limita al codice e al debug. Devi anche parlare con i collaboratori dei dati per valutare le loro esigenze, configurare il tuo ambiente, pacchettizzare il codice in un'immagine containerizzata e collaborare con un operatore dei carichi di lavoro per assicurarti che tutto venga implementato correttamente.
Parla con i collaboratori dei dati
Prima di iniziare a scrivere l'applicazione, devi parlare con i tuoi collaboratori sui dati privati su cui vuoi lavorare. Ecco alcune domande che puoi porre:
Quali sono gli ID organizzazione coinvolti?
Quali sono i numeri dei progetti coinvolti?
Quali sono le Google Cloud risorse a cui devo accedere, nonché i relativi ID e nomi?
Ci sono 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 quale 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 unici per ciascuno?
Inoltre, ogni collaboratore dei dati potrebbe avere requisiti di privacy specifici che devi soddisfare. È di fondamentale importanza che nessun dato privato venga exposto come risultato di un carico di lavoro.
Creare la soluzione Spazio riservato
È utile configurare due o più progetti con autorizzazioni appropriate come ambiente di test, ad esempio in Creare il primo ambiente Spazio riservato. Cerca di rispecchiare 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. Inoltre, puoi avere un'idea dei ruoli di operatore del carico di lavoro e collaboratore dei dati e delle relative responsabilità.
Durante la fase iniziale di creazione, è utile osservare le seguenti pratiche:
Quando collabori con i dati, riduci al minimo la convalida dell'attestazione per velocizzare lo sviluppo.
Quando lavori come operatore del carico di lavoro, utilizza l'immagine di debug di Confidential Space invece di quella di produzione durante l'esecuzione del deployment del carico di lavoro. In questo modo hai a disposizione più modi per risolvere i problemi relativi al carico di lavoro.
Man mano che l'applicazione matura e il suo stato diventa più prevedibile, puoi bloccare sempre di più la tua soluzione con la convalida dell'attestazione e i criteri di lancio, nonché passare all'immagine dello Spazio riservato di produzione.
Dopo aver fatto funzionare correttamente il tuo carico di lavoro nell'ambiente di test, puoi passare ai test nei progetti dei tuoi collaboratori con risorse reali, ma con dati falsi, in modo da dimostrare loro come funziona tutto. A questo punto, potresti iniziare a lavorare con un operatore di carichi di lavoro indipendente.
Quando tutto funziona e l'output è come previsto, puoi iniziare a eseguire test sui dati di produzione. Una volta completati i test e tutte le parti hanno approvato i risultati, il carico di lavoro è pronto per essere implementato 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 terze parti potrebbero leggere accedendo ai log. Prima che il codice inizi a funzionare in produzione, assicurati che non generi altro che 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 carico di lavoro, l'immagine Docker viene estratta dal repository Artifact Registry dall'immagine dello spazio riservato, viene eseguita e l'applicazione può iniziare a lavorare sulle risorse del progetto appropriate.
Quando crei l'immagine Docker, tieni conto di quanto segue:
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 per l'integrità di Spazio riservato, quest'ultimo memorizza i tag di integrità del disco. Questo utilizza circa l'1% di overhead di memoria per ogni byte di 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 scambio è disattivata nelle VM Confidential Space, il che significa che un utilizzo eccessivo della memoria può causare un arresto anomalo del carico di lavoro. Assicurati che la macchina selezionata supporti l'utilizzo della memoria del tuo carico di lavoro, oltre al sovraccarico per l'integrità del disco.
Token OIDC scaduti
Un token OIDC viene reso disponibile per il consumo del carico di lavoro all'avvio. Contiene rivendicazioni di attestazione verificate relative alla VM del tuo carico di lavoro e viene archiviato nel contenitore del carico di lavoro all'indirizzo/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 va a buon fine (a causa di problemi di rete, un'interruzione del servizio di attestazione o altro), il codice del carico di lavoro deve essere in grado di gestire l'errore.
Il tuo carico di lavoro 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'uso iniziale.
Attendi che il token scaduto venga aggiornato correttamente.
Esci dal carico di lavoro.
Montaggi scratch in memoria
Spazio riservato supporta l'aggiunta di spazi di lavoro in memoria. Viene utilizzata la memoria disponibile nella VM Confidential Space. Poiché lo spazio di lavoro utilizza la memoria della VM con segretezza, ha le stesse proprietà di integrità e riservatezza della VM con segretezza.
Puoi utilizzare
tee-dev-shm-size
per aumentare le dimensioni del montaggio della memoria condivisa /dev/shm per il carico di lavoro.
La dimensione /dev/shm è specificata in KB.
Puoi utilizzare
tee-mount per specificare mount di tmpfs nel contenitore in esecuzione utilizzando configurazioni separate da punto e virgola. type e source sono sempre tmpfs. destination è il mountpoint, che interagisce con il criterio di lancio tee.launch_policy.allow_mount_destinations. Se vuoi, puoi
specificare la dimensione di tmpfs in byte. La dimensione predefinita è il 50% della memoria della VM.
Porte in entrata
Per impostazione predefinita, le VM Confidential Space funzionano con una regola firewall per bloccare tutte le porte in entrata. Quando utilizzi una versione dell'immagine dello spazio riservato pari o superiore a 230600,
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 a Dockerfile, insieme al numero di porta da mantenere aperta e un protocollo facoltativo di tcp o udp. Se non specifichi il protocollo per una porta, sono consentiti sia TCP che UDP. Ecco un
Dockerfile di esempio 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 le porte che sono
già state aperte dall'immagine di base.
Gli operatori dei carichi di lavoro devono assicurarsi che le porte esposte siano aperte nel firewall del VPC prima di eseguire il carico di lavoro. I numeri di porta possono essere forniti dall'autore del carico di lavoro o estratti dalle informazioni sull'immagine Docker.
Le porte esposte vengono registrate nella console e reindirizzate a Cloud Logging
quando si utilizza la variabile di metadati tee-container-log-redirect.
Norme di lancio
I criteri di lancio sostituiscono le variabili dei metadati della VM impostate dagli operatori dei carichi di lavoro per limitare le azioni dannose. L'autore di un workload può impostare i criteri con un'etichetta durante la creazione dell'immagine del contenitore.
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"}
...
)
I criteri di lancio disponibili sono riportati nella tabella seguente:
| Norme | Tipo | Descrizione |
|---|---|---|
|
Interazione con:
|
Booleano (il valore predefinito è false) |
Determina se il valore
CMD
specificato in Dockerfile del contenitore del carico di lavoro può essere
sostituito 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 variabili di ambiente consentiti che possono essere impostati da un operatore di workload con valori dei metadati
tee-env-ENVIRONMENT_VARIABLE_NAME.
|
|
Interazione con:
|
Stringa separata da due punti |
Una stringa separata da due punti di directory di montaggio consentite a cui l'operatore del carico di lavoro è autorizzato a eseguire il montaggio 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 carico di lavoro se
I valori validi sono:
|
Più esecuzioni del carico di lavoro
Per garantire un ambiente pulito, una VM deve essere riavviata per riavviare un carico di lavoro. Il disco della VM viene criptato con una chiave temporanea per risolvere il vettore di attacco della modifica di un'immagine del carico di lavoro sul disco dopo che è stata scaricata e misurata.
Vengono aggiunti anche overhead come il tempo di avvio e il recupero dell'immagine del workload per ogni esecuzione del workload. Se questi costi aggiuntivi influiscono troppo sulle prestazioni del tuo carico di lavoro, puoi codificare un riavvio del carico di lavoro al suo interno, con il costo aggiuntivo dell'aumento del tuo profilo di rischio.
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 segmento di pubblico personalizzato.
Per ulteriori informazioni, consulta Accedere alle risorse non gestite da Google Cloud IAM.
Immagini container firmate
Puoi firmare un'immagine contenitore con una chiave pubblica, che un collaboratore dei dati può poi utilizzare per l'attestazione anziché specificare un digest dell'immagine nelle sue norme relative ai WIP.
Ciò significa che i collaboratori dei dati non devono aggiornare i propri criteri WIP ogni volta che viene aggiornato un carico di lavoro e il carico di lavoro può continuare ad accedere alle risorse protette senza interruzioni.
Puoi utilizzare Sigstore Cosign per firmare l'immagine del contenitore. Per assicurarsi che Confidential Space possa recuperare le firme, gli operatori dei carichi di lavoro devono aggiungere le informazioni sulle firme alla variabile dei metadati tee-signed-image-repos prima di eseguire il deployment del carico di lavoro.
Durante l'esecuzione, le firme vengono inviate al servizio di attestazione di 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 affermazione 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 sulle immagini container firmate.