Codelab su Trusted Space

1. Panoramica

Vuoi aumentare la sicurezza e la privacy dei tuoi carichi di lavoro con accelerazione GPU? Questo codelab ti guiderà attraverso le funzionalità di Trusted Space, un'offerta che fornisce un forte isolamento degli operatori e il supporto degli acceleratori per i tuoi workload AI/ML sensibili.

Proteggere dati, modelli e chiavi di valore è più importante che mai. Trusted Space offre una soluzione garantendo che i tuoi workload operino in un ambiente sicuro e attendibile in cui anche l'operatore del workload non ha accesso.

Ecco cosa offre Trusted Space:

• Privacy e sicurezza avanzate: Trusted Space fornisce un Trusted Execution Environment in cui i tuoi asset sensibili (ad es. modelli, dati e chiavi di valore) rimangono protetti, grazie a prove crittografiche.
• Isolamento degli operatori: elimina le preoccupazioni relative all'interferenza degli operatori. Con Trusted Space, anche gli operatori dei workload non hanno accesso, il che impedisce loro di eseguire SSH, accedere ai dati, installare software o manomettere il codice.
• Supporto degli acceleratori: Trusted Space è progettato per funzionare senza problemi con un'ampia gamma di acceleratori hardware, tra cui GPU come H100, A100, T4 e L4. In questo modo, le applicazioni AI/ML sensibili alle prestazioni vengono eseguite senza problemi.

Cosa imparerai a fare

• Comprendere le offerte chiave di Trusted Space.
• Scopri come eseguire il deployment e configurare un ambiente Trusted Space per proteggere le risorse di valore del tuo workload AI/ML.

Che cosa ti serve

• Un progetto Google Cloud
• Conoscenza di base di Google Compute Engine e degli acceleratori.
• Conoscenza di base di service account, gestione delle chiavi, federazione delle identità per i workload e condizioni degli attributi.
• Conoscenza di base di container e Artifact Registry

Proteggere i prompt di generazione di codice sensibili con Primus Company

In questo codelab, ci metteremo nei panni di Primus, un'azienda che dà la priorità alla privacy e alla sicurezza dei dati dei propri dipendenti. Primus vuole eseguire il deployment di un modello di generazione di codice per aiutare i suoi sviluppatori nelle attività di programmazione. Tuttavia, l'azienda è preoccupata di proteggere la riservatezza dei prompt inviati dai dipendenti, in quanto questi prompt spesso contengono snippet di codice sensibili, dettagli di progetti interni o algoritmi proprietari.

Perché Primus Company non si fida dell'operatore?

Primus Corp opera in un mercato altamente competitivo. La sua codebase contiene proprietà intellettuale di valore, inclusi algoritmi proprietari e snippet di codice sensibili che forniscono un vantaggio competitivo. L'azienda è preoccupata della possibilità di spionaggio aziendale da parte degli operatori dei workload. Inoltre, i prompt dei dipendenti potrebbero includere parti di codice riservate che devono esserne a conoscenza e che Primus Corp vuole proteggere.

Per risolvere questo problema, Primus Corp utilizzerà Trusted Space per isolare il server di inferenza che esegue il modello per la generazione di codice. Ecco come funziona:

• Crittografia dei prompt: prima di inviare un prompt al server di inferenza, ogni dipendente lo cripta utilizzando una chiave KMS gestita da Primus Corp in Google Cloud. In questo modo, solo l'ambiente Trusted Space, in cui è disponibile la chiave di decrittografia corrispondente, può decriptare il prompt e accedere al testo non crittografato. In uno scenario reale, la crittografia lato client può essere gestita dalle librerie disponibili (ad es. tink). Nell'ambito di questo codelab, utilizzeremo questa applicazione client di esempio con la crittografia envelope.
• Isolamento degli operatori: solo il server di inferenza, in esecuzione in un ambiente Trusted Space, avrà accesso alla chiave utilizzata per la crittografia e sarà in grado di decriptare il prompt in un ambiente attendibile. L'accesso alla chiave di crittografia sarà protetto dal pool di identità del workload. Grazie alle garanzie di isolamento di Trusted Space, nemmeno l'operatore del workload può accedere alla chiave utilizzata per la crittografia e ai contenuti decriptati.
• Inferenza sicura utilizzando gli acceleratori: il server di inferenza verrà avviato su una Shielded VM (nell'ambito della configurazione di Trusted Space), il che garantirà che l'istanza del workload non sia stata compromessa da malware o rootkit a livello di boot o di kernel. Questo server decripta il prompt nell'ambiente Trusted Space, esegue l'inferenza utilizzando il modello di generazione di codice e restituisce il codice generato al dipendente.

2. Configurare le risorse cloud

Prima di iniziare

• Clona questo repository utilizzando il comando riportato di seguito per ottenere gli script necessari utilizzati nell'ambito di questo codelab.

git clone https://github.com/GoogleCloudPlatform/confidential-space.git

• Cambia la directory per questo codelab.

cd confidential-space/codelabs/trusted_space_codelab/scripts

• Assicurati di aver impostato le variabili di ambiente del progetto richieste come mostrato di seguito. Per ulteriori informazioni sulla configurazione di un progetto Google Cloud, consulta questo codelab. Puoi fare riferimento a questo per scoprire come recuperare l'ID progetto e in che modo è diverso dal nome e dal numero del progetto.

export PRIMUS_PROJECT_ID=<GCP project id of Primus>

• Abilita la fatturazione per i tuoi progetti.
• Abilita l'API Confidential Computing e le seguenti API per entrambi i progetti.

gcloud services enable \
    cloudapis.googleapis.com \
    cloudresourcemanager.googleapis.com \
    cloudkms.googleapis.com \
    cloudshell.googleapis.com \
    container.googleapis.com \
    containerregistry.googleapis.com \
    iam.googleapis.com \
    confidentialcomputing.googleapis.com

• Assegna i valori alle variabili per i nomi delle risorse specificati sopra utilizzando il seguente comando. Queste variabili ti consentono di personalizzare i nomi delle risorse in base alle esigenze e di utilizzare le risorse esistenti se sono già state create. (ad es.export PRIMUS_SERVICE_ACCOUNT='my-service-account')

1. Puoi impostare le seguenti variabili con i nomi delle risorse cloud esistenti nel progetto Primus. Se la variabile è impostata, verrà utilizzata la risorsa cloud esistente corrispondente del progetto Primus. Se la variabile non è impostata, il nome della risorsa cloud verrà generato dal nome del progetto e verrà creata una nuova risorsa cloud con quel nome. Di seguito sono riportate le variabili supportate per i nomi delle risorse:

$PRIMUS_PROJECT_REGION	Regione in cui verranno create le risorse regionali per Primus Company.
$PRIMUS_SERVICE_LOCATION	Località in cui verranno create le risorse per Primus Company.
$PRIMUS_PROJECT_ZONE	Zona in cui verranno create le risorse zonali per Primus Company.
$PRIMUS_WORKLOAD_IDENTITY_POOL	Pool di identità del workload di Primus Company per proteggere le risorse cloud.
$PRIMUS_WIP_PROVIDER	Provider del pool di identità del workload di Primus Company che include la condizione di autorizzazione da utilizzare per i token firmati dal servizio di verifica dell'attestazione.
$PRIMUS_SERVICEACCOUNT	Service account di Primus Company utilizzato da $PRIMUS_WORKLOAD_IDENTITY_POOL per accedere alle risorse protette. In questo passaggio, ha l'autorizzazione a visualizzare i dati dei clienti archiviati nel bucket $PRIMUS_INPUT_STORAGE_BUCKET.
$PRIMUS_ENC_KEY	La chiave KMS viene utilizzata per criptare i prompt forniti dai dipendenti di Primus Company.
$PRIMUS_ENC_KEYRING	Il portachiavi KMS che verrà utilizzato per creare la chiave di crittografia $PRIMUS_ENC_KEY per Primus Company.
$PRIMUS_ENC_KEYVERSION	La versione della chiave KMS della chiave di crittografia $PRIMUS_ENC_KEY. Il valore predefinito è 1. Aggiorna questo valore se utilizzi una chiave esistente che è stata ruotata in passato e la cui versione è stata aggiornata.
$PRIMUS_ARTIFACT_REPOSITORY	Il repository di artefatti in cui verrà eseguito il push dell'immagine Docker del workload.
$PRIMUS_PROJECT_REPOSITORY_REGION	La regione del repository di artefatti che conterrà l'immagine Docker del workload pubblicata.
$WORKLOAD_VM	Nome della VM del workload.
$WORKLOAD_IMAGE_NAME	Nome dell'immagine Docker del workload.
$WORKLOAD_IMAGE_TAG	Tag dell'immagine container del workload.
$WORKLOAD_SERVICEACCOUNT	Il service account che ha l'autorizzazione ad accedere alla Confidential VM che esegue il workload.
$CLIENT_VM	Nome della VM client che eseguirà l'applicazione client del server di inferenza.
$CLIENT_SERVICEACCOUNT	Il service account utilizzato da $CLIENT_VM.

• Per il progetto $PRIMUS_PROJECT_ID, avrai bisogno dei ruoli Amministratore dello spazio di archiviazione, Amministratore di Artifact Registry, Amministratore di Cloud KMS, Amministratore account di servizio e Amministratore del pool di identità del workload IAM. Puoi consultare questa guida su come concedere i ruoli IAM utilizzando la console Google Cloud.
• Per il $PRIMUS_PROJECT_ID, esegui il seguente script per impostare i nomi delle variabili rimanenti su valori basati sull'ID progetto per i nomi delle risorse.

source config_env.sh

Nota: per un'esperienza senza interruzioni, ti consigliamo di utilizzare Cloud Shell per questo codelab. Se utilizzi un terminale normale, dovrai ripetere questo passaggio se chiudi il terminale e accedi di nuovo. Cloud Shell gestisce automaticamente le riconnessioni.

Configurare le risorse di Primus Company

Nell'ambito di questo passaggio, configurerai le risorse cloud richieste per Primus. Esegui il seguente script per configurare le risorse per Primus. Durante l'esecuzione dello script verranno create le seguenti risorse:

• Chiave di crittografia ($PRIMUS_ENC_KEY) e portachiavi ($PRIMUS_ENC_KEYRING) in KMS per criptare il file di dati dei clienti di Primus Company.
• Pool di identità del workload ($PRIMUS_WORKLOAD_IDENTITY_POOL) per convalidare le attestazioni in base alle condizioni degli attributi configurate nel relativo provider.
• Il service account ($PRIMUS_SERVICE_ACCOUNT) collegato al pool di identità del workload menzionato sopra ($PRIMUS_WORKLOAD_IDENTITY_POOL) ha accesso alla decrittografia dei dati utilizzando la chiave KMS (utilizzando il ruolo roles/cloudkms.cryptoKeyDecrypter), alla crittografia dei dati utilizzando la chiave KMS (utilizzando il ruolo roles/cloudkms.cryptoKeyEncrypter), alla lettura dei dati dal bucket Cloud Storage (utilizzando il ruolo objectViewer) e al collegamento del service account al pool di identità del workload (utilizzando il ruolo roles/iam.workloadIdentityUser).

./setup_primus_resources.sh

Nota: se esegui di nuovo questo codelab e riscontri errori come ALREADY_EXISTS durante la creazione della chiave KMS o del pool di identità del workload, è probabile che le risorse siano state eliminate temporaneamente dalle esecuzioni precedenti. Poiché queste risorse non possono essere riutilizzate per 30 giorni, dovrai crearle con nomi diversi.

Per farlo, utilizza i seguenti comandi per impostare nuovi nomi per il pool di identità del workload e la chiave KMS:

export PRIMUS_WORKLOAD_IDENTITY_POOL=<new name of Workload Identity Pool>

export PRIMUS_ENC_KEY=<new name of KMS Key>

Quindi, esegui di nuovo lo script ./setup_primus_resources.sh come indicato in precedenza.

3. Creare il workload

Creare il service account del workload

Ora creerai un service account per il workload con i ruoli e le autorizzazioni richiesti. Esegui il seguente script per creare un service account del workload nel progetto Primus. Questo service account verrà utilizzato dalla VM che esegue il server di inferenza.

Questo service account del workload ($WORKLOAD_SERVICEACCOUNT) avrà i seguenti ruoli:

• confidentialcomputing.workloadUser per ottenere un token di attestazione
• logging.logWriter per scrivere i log in Cloud Logging.

./create_workload_service_account.sh

Creare il workload

Nell'ambito di questo passaggio, creerai un'immagine Docker del workload. Il workload verrà creato da Primus Company. Il workload utilizzato in questo codelab è codice Python che utilizza il modello codegemma dal bucket GCS disponibile pubblicamente (del modello di Vertex AI Garden). Il workload caricherà il modello codegemma e avvierà il server di inferenza che gestirà le richieste di generazione di codice degli sviluppatori di Primus.

Nella richiesta di generazione di codice, il workload riceverà la DEK criptata insieme a un prompt criptato. Il workload effettuerà quindi la chiamata all'API KMS per decriptare la DEK e poi decripterà il prompt utilizzando questa DEK. Le chiavi di crittografia (per la DEK) saranno protette tramite il pool di identità del workload e l'accesso verrà concesso ai workload che soddisfano le condizioni degli attributi. Queste condizioni degli attributi sono descritte in modo più dettagliato nella sezione successiva sull'autorizzazione del workload. Una volta che il server di inferenza ha il prompt decriptato, genererà il codice utilizzando un modello caricato e restituirà la risposta.

Esegui il seguente script per creare un workload in cui vengono eseguiti i seguenti passaggi:

• Crea Artifact Registry($PRIMUS_ARTIFACT_REGISTRY) di proprietà di Primus.
• Aggiorna il codice del workload con i nomi delle risorse richiesti.
• Crea il workload del server di inferenza e crea il Dockerfile per creare un'immagine Docker del codice del workload. Ecco il Dockerfile utilizzato per questo codelab.
• Crea e pubblica l'immagine Docker in Artifact Registry ($PRIMUS_ARTIFACT_REGISTRY) di proprietà di Primus.
• Concedi a $WORKLOAD_SERVICEACCOUNT l'autorizzazione di lettura per $PRIMUS_ARTIFACT_REGISTRY. Questa operazione è necessaria affinché il container del workload possa eseguire il pull dell'immagine Docker del workload da Artifact Registry.

./create_workload.sh

Per riferimento, ecco il metodo generate() del workload creato e utilizzato in questo codelab (puoi trovare l'intero codice del workload qui).

def generate():
  try:
    data = request.get_json()
    ciphertext = base64.b64decode(data["ciphertext"])
    wrapped_dek = base64.b64decode(data["wrapped_dek"])
    unwrapped_dek_response = kms_client.decrypt(
        request={"name": key_name, "ciphertext": wrapped_dek}
    )
    unwrapped_dek = unwrapped_dek_response.plaintext
    f = Fernet(unwrapped_dek)
    plaintext = f.decrypt(ciphertext)
    prompt = plaintext.decode("utf-8")
    tokens = tokenizer(prompt, return_tensors="pt")
    outputs = model.generate(**tokens, max_new_tokens=128)
    generated_code = tokenizer.decode(outputs[0])
    generated_code_bytes = generated_code.encode("utf-8")

    response = f.encrypt(generated_code_bytes)
    ciphertext_base64 = base64.b64encode(response).decode("utf-8")
    response = {"generated_code_ciphertext": ciphertext_base64}
    return jsonify(response)

  except (ValueError, TypeError, KeyError) as e:
    return jsonify({"error": str(e)}), 500

4. Autorizzare ed eseguire il workload

Autorizzare il workload

Primus vuole autorizzare i workload ad accedere alla chiave KMS utilizzata per la crittografia dei prompt in base agli attributi delle seguenti risorse:

• _Cosa_: codice verificato
• Dove: un ambiente sicuro
• Chi: un operatore attendibile

Primus utilizza la federazione delle identità per i workload per applicare un criterio di accesso basato su questi requisiti. La federazione delle identità per i workload consente di specificare le condizioni degli attributi. Queste condizioni limitano le identità che possono eseguire l'autenticazione con il pool di identità del workload (WIP). Puoi aggiungere il servizio di verifica dell'attestazione al WIP come provider del pool di identità del workload per presentare le misurazioni e applicare il criterio.

Il pool di identità del workload è già stato creato in precedenza nell'ambito del passaggio di configurazione delle risorse cloud. Ora Primus creerà un nuovo provider del pool di identità del workload OIDC. La --attribute-condition specificata autorizza l'accesso al container del workload. Richiede:

• Cosa: l'ultima $WORKLOAD_IMAGE_NAME caricata nel repository $PRIMUS_ARTIFACT_REPOSITORY.
• Dove: l'ambiente di esecuzione attendibile di Confidential Space è in esecuzione sull'immagine VM di Confidential Space completamente supportata.
• Chi: il service account di Primus $WORKLOAD_SERVICE_ACCOUNT.

export WORKLOAD_IMAGE_DIGEST=$(gcloud artifacts docker images describe ${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/$PRIMUS_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG  --format="value(image_summary.digest)" --project ${PRIMUS_PROJECT_ID})

gcloud iam workload-identity-pools providers create-oidc $PRIMUS_WIP_PROVIDER \
  --location="global" \
  --project="$PRIMUS_PROJECT_ID" \
  --workload-identity-pool="$PRIMUS_WORKLOAD_IDENTITY_POOL" \
  --issuer-uri="https://confidentialcomputing.googleapis.com/" \
  --allowed-audiences="https://sts.googleapis.com" \
  --attribute-mapping="google.subject='assertion.sub'" \
  --attribute-condition="assertion.swname == 'HARDENED_SHIELDED' && assertion.hwmodel == 'GCP_SHIELDED_VM' && 
assertion.submods.container.image_digest == '${WORKLOAD_IMAGE_DIGEST}' &&
 assertion.submods.container.image_reference == '${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/$PRIMUS_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG' && 
'$WORKLOAD_SERVICEACCOUNT@$PRIMUS_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts"

Il comando riportato sopra verifica che il workload sia in esecuzione in un ambiente Trusted Space controllando che hwmodel sia impostato su "GCP_SHIELDED_VM" e swname sia impostato su "HARDENED_SHIELDED". Inoltre, include asserzioni specifiche del workload, come image_digest e image_reference, per migliorare la sicurezza e garantire l'integrità del workload in esecuzione.

Eseguire il workload

Nell'ambito di questo passaggio, eseguiremo il workload nella VM Trusted Space a cui sarà collegato un acceleratore. Gli argomenti TEE richiesti vengono passati utilizzando il flag dei metadati. Gli argomenti per il container del workload vengono passati utilizzando la parte "tee-cmd" del flag. Per dotare la VM del workload di una GPU Nvidia Tesla T4, utilizzeremo il flag --accelerator=type=nvidia-tesla-t4,count=1. In questo modo, una GPU verrà collegata alla VM. Dovremo anche includere tee-install-gpu-driver=true nei flag dei metadati per attivare l'installazione del driver GPU appropriato.

gcloud compute instances create ${WORKLOAD_VM} \
  --accelerator=type=nvidia-tesla-t4,count=1 \
  --machine-type=n1-standard-16 \
  --shielded-secure-boot \
  --image-project=conf-space-images-preview \
  --image=confidential-space-0-gpupreview-796705b \
  --zone=${PRIMUS_PROJECT_ZONE} \
  --maintenance-policy=TERMINATE \
  --boot-disk-size=40 \
  --scopes=cloud-platform \
  --service-account=${WORKLOAD_SERVICEACCOUNT}@${PRIMUS_PROJECT_ID}.iam.gserviceaccount.com \
  --metadata="^~^tee-image-reference=${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_ARTIFACT_REPOSITORY}/${WORKLOAD_IMAGE_NAME}:${WORKLOAD_IMAGE_TAG}~tee-install-gpu-driver=true~tee-restart-policy=Never"

Nota: esistono due immagini che puoi utilizzare per l'istanza: confidential-space-0-gpupreview-796705b e confidential-space-debug-0-gpupreview-796705b. Puoi utilizzare una delle due. La differenza principale è che confidential-space-0-gpupreview-796705b ha i servizi disabilitati, il che non consente all'operatore di interferire con il workload, mentre confidential-space-debug-0-gpupreview-796705b avrà SSH abilitato e l'operatore potrà eseguire SSH nella VM. In questo modo, l'operatore potrà eseguire il debug (ma il servizio di attestazione annoterà nel token di attestazione che lo stato di debug è abilitato). Tuttavia, dovrai arrestare manualmente la VM in un secondo momento.

Eseguire la query di inferenza

Dopo l'avvio del server di inferenza del workload, i dipendenti di Primus Company possono inviare le richieste di generazione di codice al server di inferenza.

Nota: l'avvio del server di inferenza richiede circa 8-10 minuti. Attendi che il server sia completamente pronto prima di eseguire i seguenti comandi.

Nell'ambito di questo codelab, utilizzeremo il seguente script per configurare l'applicazione client che interagirà con il server di inferenza. Esegui questo script per configurare la VM client.

./setup_client.sh

I seguenti passaggi mostrano come eseguire SSH nella VM client ed eseguire un'applicazione client di esempio in un ambiente virtuale Python. Questa applicazione di esempio utilizza la crittografia envelope con la libreria Fernet, ma tieni presente che le librerie di crittografia specifiche possono essere adattate a diversi casi d'uso.

gcloud compute ssh ${CLIENT_VM} --zone=${PRIMUS_PROJECT_ZONE}

Esegui i seguenti comandi per attivare l'ambiente virtuale Python nella VM client ed eseguire l'applicazione client.

source venv/bin/activate

python3 inference_client.py

L'output di questa applicazione client di esempio mostrerà le richieste di prompt di crittografia e di testo non crittografato e le risposte criptate e decriptate corrispondenti.

5. Esegui la pulizia

Ecco lo script che può essere utilizzato per liberare spazio dalle risorse che abbiamo creato nell'ambito di questo codelab. Nell'ambito di questa pulizia, verranno eliminate le seguenti risorse:

• Service account di Primus ($PRIMUS_SERVICEACCOUNT).
• Chiave di crittografia di Primus ($PRIMUS_ENC_KEY).
• Repository di artefatti di Primus ($PRIMUS_ARTIFACT_REPOSITORY).
• Pool di identità del workload di Primus ($PRIMUS_WORKLOAD_IDENTITY_POOL) con il relativo provider.
• Service account del workload di Primus ($WORKLOAD_SERVICEACCOUNT).
• VM del workload ($WORKLOAD_VM) e VM client ($CLIENT_VM).

./cleanup.sh

Se hai finito di esplorare, ti consigliamo di eliminare il progetto.

• Vai alla console Google Cloud
• Seleziona il progetto che vuoi chiudere, quindi fai clic su "Elimina" nella parte superiore: il progetto verrà programmato per l'eliminazione