L'immagine Confidential Space che esegue il carico di lavoro è un sistema operativo minimo a uso specifico. È basato sui miglioramenti della sicurezza esistenti di Container-Optimized OS e aggiunge i seguenti vantaggi:
Partizioni disco criptate con protezione dell'integrità
Connessioni di rete criptate e autenticate
Varie misure dello stivale
Disattiva l'accesso remoto e gli strumenti specifici per il cloud
Transizioni di stato ridotte
Tipi di immagini Confidential Space
L'immagine Confidential Space è disponibile in due varianti: produzione ed debug. La versione di debug è considerata non sicura e viene utilizzata per testare il carico di lavoro su dati non di produzione. Si differenzia dall'immagine di produzione per i seguenti aspetti:
SSH è attivo.
L'operatore ha accesso root alla VM che esegue il carico di lavoro.
L'istanza VM che esegue l'immagine di debug non si arresta dopo il completamento del carico di lavoro.
Per scoprire di più su come specificare l'immagine da utilizzare, consulta Opzioni e metadati delle VM.
Ciclo di vita di un'immagine Confidential Space
Quando crei una Confidential VM tramite l'immagine Confidential Space, viene utilizzata l'ultima versione dell'immagine. Se elimini sempre la Confidential VM al termine del carico di lavoro e ne crei una nuova ogni volta che esegui il carico di lavoro, puoi avere la certezza che l'immagine sia aggiornata ogni volta che esegui il carico di lavoro.
Tuttavia, i carichi di lavoro a lunga esecuzione o un carico di lavoro su una VM creata in passato comportano il rischio di utilizzare versioni precedenti dell'immagine Confidential Space, il che potrebbe introdurre vulnerabilità di sicurezza.
In qualità di collaboratore dei dati, puoi impedire ai carichi di lavoro di accedere ai tuoi dati a meno che non vengano eseguiti sull'immagine Confidential Space più recente. Per farlo, aggiungi l'asserzione support_attributes al provider del pool di identità del carico di lavoro.
Per visualizzare le versioni delle immagini di Confidential Space, vedi Versioni delle immagini.
Carichi di lavoro e immagini container riproducibili
Un carico di lavoro può essere aggiunto tramite Docker o altri software container. Creare un'immagine container in modo riproducibile può contribuire ad aumentare la fiducia tra le parti. Se utilizzi Docker, puoi creare immagini riproducibili con Bazel.
Limiti di memoria e disco
Lo spazio su disco totale disponibile per Confidential Space è di circa 7 GB. Ciò include l'immagine del carico di lavoro e qualsiasi scrittura su disco durante il carico di lavoro.
Assicurati di rispettare i limiti di memoria delle VM. La memoria di scambio è disabilitata sulle VM di Confidential Space, il che significa che un utilizzo eccessivo di memoria può causare l'arresto anomalo del carico di lavoro.
Più esecuzioni di carichi di lavoro
Per garantire un ambiente pulito, è necessario riavviare una VM per riavviare un carico di lavoro. Cripta il disco della VM con una chiave temporanea, per affrontare il vettore di attacco della modifica di un'immagine del carico di lavoro sul disco dopo che è stato scaricato e misurato.
Vengono aggiunti anche costi generali come il tempo di avvio e il pull dell'immagine del carico di lavoro in ogni esecuzione del carico di lavoro. Se queste spese generali hanno un impatto eccessivo sulle prestazioni del tuo carico di lavoro, puoi programmare un riavvio di un carico di lavoro nel carico di lavoro stesso, con il costo di aumentare il tuo profilo di rischio.
Token OIDC scaduti
Un token OIDC viene reso disponibile al tuo carico di lavoro quando viene avviato. Contiene dichiarazioni attestanti verificate sulla VM del carico di lavoro e viene archiviato nel container del carico di lavoro all'indirizzo /run/container_launcher/attestation_verifier_claims_token. Il token scade dopo 60 minuti.
Se il token scade, viene eseguito un tentativo di aggiornamento in background utilizzando il backoff esponenziale fino al completamento dell'operazione. 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 tuo carico di lavoro deve essere in grado di gestire tale 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ù richiesto dopo l'utilizzo iniziale.
- Attendi che il token scaduto venga aggiornato correttamente.
- Esci dal carico di lavoro.
Logging
Come qualsiasi programma a riga di comando, il carico di lavoro stdout e stderr può essere visualizzato nella console che esegue il carico di lavoro. Facoltativamente, questo criterio può essere nascosto all'operatore tramite il criterio di lancio di log_redirect.
Inoltre, il carico di lavoro stdout e stderr può essere reindirizzato a Cloud Logging impostando la chiave dei metadati tee-container-log-redirect su true nella VM Confidential Space e garantendo che l'account di servizio che esegue il carico di lavoro abbia il ruolo logging.logWriter.
Per ridurre il tuo profilo di rischio, registra la quantità minima di informazioni e non registrare informazioni sensibili.
Codici da restituire
Come altri contenuti stdout e stderr, i codici di ritorno vengono visualizzati nella console durante l'esecuzione di Avvio app e del carico di lavoro e possono essere reindirizzati a Cloud Logging.
I codici di reso sono descritti nella seguente tabella:
| Codice | Definizione | Comportamento di arresto delle VM |
|---|---|---|
| 0 | Il carico di lavoro è stato completato correttamente quando è stata utilizzata l'immagine di produzione. | La VM si arresta al termine del carico di lavoro. |
| 1 | Il carico di lavoro o Avvio app hanno restituito un errore durante l'utilizzo dell'immagine di produzione. | La VM si arresta dopo aver restituito un errore. |
| 3 | Avvio app dopo un errore in quanto dovuto a tee-restart-policy. |
La VM viene riavviata. |
| 4 | L'esecuzione del carico di lavoro o dell'utilità di avvio è terminata quando si utilizza l'immagine di debug e la VM è ora inattiva. | La VM non si arresta dopo il completamento del carico di lavoro o restituisce un errore. In questo modo puoi eseguire il debug del carico di lavoro su SSH. |
Se un carico di lavoro non va a buon fine, un operatore del carico di lavoro riceve solo il messaggio workload finished with a non-zero return code, senza ulteriore contesto. Per
un'immagine di produzione, è possibile impostare Avvio app sul riavvio in caso di errore con
tee-restart-policy=OnFailure.
Criteri di lancio
Quando crei un carico di lavoro, puoi specificare criteri che sostituiscono le variabili di metadati delle VM, che limitano la capacità di un operatore dannoso.
I criteri di lancio sono impostati su un'etichetta.
Ad esempio, in un Dockerfile:
LABEL: "tee.launch_policy.allow_cmd_override"="true"
In un file Bazel BUILD:
container_image(
...
labels={"tee.launch_policy.allow_cmd_override":"true"}
...
)
Le norme per il lancio disponibili sono le seguenti:
| Criterio | Valore | Descrizione |
|---|---|---|
tee.launch_policy.allow_cmd_override |
Booleano (il valore predefinito è false) |
Determina se
CMD
specificato in Dockerfile può essere sostituito dal valore dei metadati
tee-cmd.
|
tee.launch_policy.allow_env_override |
Stringa separata da virgole |
Una stringa di nomi delle variabile di ambiente separati da virgole che possono essere sovrascritti dai valori dei metadati tee-env-ENVIRONMENT_VARIABLE_NAME.
|
tee.launch_policy.log_redirect |
debugonly (default), always o
never
|
Determina come funziona il logging se "tee-container-log-redirect" è impostato su
|