Un workload viene creato da un autore del workload ed elabora i dati riservati con cui i collaboratori vogliono lavorare.
Un autore di workload deve mettere insieme le seguenti risorse per creare un workload:
Un'applicazione per elaborare i dati riservati. Puoi scrivere la tua applicazione in qualsiasi linguaggio, a condizione che tu crei un'immagine containerizzata che lo supporti.
Un'immagine containerizzata in cui pacchettizzare l'applicazione, utilizzando Docker.
Un repository in Artifact Registry in cui archiviare l'immagine Docker.
Policy di lancio impostate sull'immagine container che controllano il modo in cui un workload può essere eseguito e limitano la capacità di un operatore di workload dannoso.
Per eseguire il deployment del workload, un operatore del workload esegue una Confidential VM 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
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 l'ambiente, pacchettizzare 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 tuoi collaboratori dei dati privati su cui vogliono che tu lavori. Ecco alcune domande che puoi porre:
Quali sono gli ID organizzazione coinvolti?
Quali sono i numeri di progetto coinvolti?
Quali sono le risorse Google Cloud a cui devo accedere e quali sono i loro ID e nomi?
Devo accedere a risorse non gestite da IAM di Google Cloud?
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?
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 unici per ciascuno?
Inoltre, ogni collaboratore ai dati potrebbe avere requisiti di privacy unici che devi soddisfare. È di vitale importanza che nessun dato privato venga esposto come risultato 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 Crea il tuo primo ambiente Confidential Space. Cerca di rispecchiare il più possibile le configurazioni dei progetti dei collaboratori ai dati. In questo modo, potrai acquisire esperienza con le autorizzazioni tra progetti e recuperare i dati di cui hai bisogno da risorse Google Cloud specifiche. Può anche aiutarti a comprendere i ruoli di operatore del workload e collaboratore ai dati e le relative responsabilità.
Durante la fase iniziale di creazione, è utile osservare le seguenti pratiche:
Quando lavori come collaboratore ai 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 bloccare sempre di più la soluzione con la convalida dell'attestazione e le policy di lancio e passare all'immagine Confidential Space di produzione.
Dopo aver fatto funzionare correttamente il workload nel tuo ambiente di test, puoi passare ai test nei progetti dei collaboratori ai dati con risorse reali, ma dati fittizi, in modo da mostrare ai collaboratori ai 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 i test sui dati di produzione. Una volta completati i 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. Fornire 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 di 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 di integrità di Confidential Space, Confidential Space archivia i tag di integrità del disco in memoria. Questo comporta 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 non superare 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 macchina selezionata supporti la memoria utilizzata del workload, oltre all'overhead di integrità del disco.
Arresti normali
Quando un operatore richiede l'arresto di una VM Confidential Space, l'Avvio Confidential Space tenta di arrestare il workload in modo controllato inviando un segnale SIGTERM. Al momento della ricezione, il workload ha fino a 120 secondi per eseguire la pulizia prima che l'Avvio app di Confidential Space avvii il processo di arresto. I workload che non implementano la gestione degli indicatori SIGTERM terminano immediatamente dopo la ricezione dell'indicatore.
Montaggi temporanei in memoria
Confidential Space supporta l'aggiunta di spazi temporanei in memoria. In questo modo viene utilizzata la memoria disponibile nella VM Confidential Space. Poiché lo spazio temporaneo 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 la policy di lancio tee.launch_policy.allow_mount_destinations. Se vuoi, 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 immagine di Confidential Space 230600 o successiva, puoi specificare le porte in entrata da mantenere aperte in Dockerfile durante la creazione dell'immagine del workload.
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 di 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 che utilizzi, 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 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 utilizzi la variabile dei metadati tee-container-log-redirect.
Norme di lancio
Le policy di lancio sostituiscono le variabili dei metadati della VM impostate dagli operatori dei workload per limitare le azioni dannose. Un autore di workload può impostare policy con un'etichetta nell'ambito della 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 lancio disponibili sono riportate nella tabella seguente:
| Policy | Tipo | Descrizione |
|---|---|---|
|
Interazione con:
|
Booleano (il valore predefinito è false) |
Determina se l'operatore del workload può aggiungere ulteriori funzionalità Linux al container del workload. |
|
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
CMD
specificato nel Dockerfile del container del workload può essere
sostituito da un operatore del workload 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 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 in cui l'operatore del workload può eseguire il montaggio utilizzando Ad esempio: |
|
Interazione con:
|
Stringa definita |
Determina il funzionamento del logging se
I valori validi sono i seguenti:
|
|
Interazione con:
|
Stringa definita |
Determina il funzionamento del monitoraggio della memoria utilizzata dal workload se
I valori validi sono i seguenti:
|
|
Interazione con:
|
Stringa definita |
Determina se limitare i privilegi di esecuzione del container. I valori validi sono i seguenti:
|
Più esecuzioni di workload
Per eseguire nuovamente 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 temporanea.
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 il pull dell'immagine del workload in ogni esecuzione del workload. Se questi overhead influiscono troppo sulle prestazioni del workload, a scapito di un aumento del profilo di rischio, puoi programmare un riavvio del workload all'interno del workload stesso.
Cgroup con spazi dei nomi
Il workload di Confidential Space viene eseguito senza un montaggio cgroup per impostazione predefinita.
Per gestire i cgroup all'interno del container del workload, puoi utilizzare
tee-cgroup-ns. Questa chiave dei metadati indica all'istanza VM di creare un montaggio in /sys/fs/cgroup nel file system del container.
Esecuzione di container non root
Se vuoi, puoi eseguire un container come utente non root per ridurre l'impatto di un container breakout. Quando l'esecuzione di container non root è abilitata, Confidential Space configura uno spazio dei nomi utente Linux e uno spazio dei nomi di rete per il workload. Gli UID e i GID dei container 0-65535 vengono mappati a ID non privilegiati a partire da 100000 sulla Confidential VM. Un processo eseguito come root all'interno del container o che ne esce ha solo accesso non privilegiato alla VM. Non è necessario aggiungere un'istruzione USER al file Dockerfile.
L'esecuzione non root richiede l'immagine Confidential Space confidential-space-261001
o versioni successive. Puoi configurarlo come facoltativo o obbligatorio:
Autore del workload: utilizza l'etichetta della policy di lancio
tee.launch_policy.nonroot_containernell'immagine container. Se questa policy viene impostata sunonrootonly, l'operatore del workload deve eseguire il container come utente non root.Operatore del workload: passa la variabile dei metadati
tee-nonroot-container=truedurante la creazione della VM. Se l'autore del workload impostanonrootonly, questa variabile dei metadati è obbligatoria, altrimenti la VM non riesce ad avviare il workload.
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 saperne di più, consulta Accedi alle risorse non gestite da Google Cloud IAM.
Immagini container firmate
Puoi firmare un'immagine container con una chiave pubblica, che un collaboratore ai dati può poi 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 un workload viene aggiornato e il workload può continuare ad accedere alle risorse protette senza interruzioni.
Puoi utilizzare Sigstore Cosign per firmare l'immagine container. Affinché Confidential Space possa recuperare le firme, gli operatori del workload devono aggiungere le informazioni sulla firma alla variabile dei metadati tee-signed-image-repos 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 delle rivendicazioni che contiene le rivendicazioni della firma verificata. 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 sull'immagine container firmata.