Valutazione automatica del codice con Agent Sandbox su GKE

1. Introduzione

In questo codelab, eseguirai il deployment dell'applicazione Hackathon Judge su Google Kubernetes Engine (GKE) e utilizzerai Kubernetes-sigs Agent Sandbox per eseguire carichi di lavoro agentici in modo sicuro.

La piattaforma è progettata per automatizzare il processo di revisione, test e valutazione dei progetti di hackathon utilizzando agenti LLM. Poiché la valutazione richiede l'analisi di invii di codice di partecipanti non attendibili, una sandbox di esecuzione sicura è fondamentale per impedire l'iniezione di codice, l'escalation dei privilegi o l'abuso di risorse.

In questo lab proverai a:

• Esegui il provisioning dei servizi Google Cloud di destinazione e stabilisci le API di destinazione.
• Inizializza GKE Autopilot e installa le CRD di Agent Sandbox, le configurazioni del cluster e il router sandbox.
• Esegui il deployment del gateway sandbox, del modello di richiesta sandbox e di un warm pool sandbox.
• Esegui il deployment dell'API REST Backend, dell'agente di valutazione ADK e della UI frontend React.
• Collega il routing con bilanciamento del carico esterno e accedi alla piattaforma per eseguire workflow di valutazione sicuri e in sandbox.

Che cosa ti serve

• Un browser web come Chrome.
• Un progetto Google Cloud con la fatturazione abilitata.

Le risorse create in questo codelab dovrebbero costare meno di 5 $in totale per i costi di runtime.

2. Il problema: valutare in modo sicuro il codice non attendibile

Gli hackathon sono eventi di innovazione frenetici in cui i partecipanti creano e inviano progetti, spesso includendo il codice sorgente, per la valutazione. La valutazione manuale di questi invii richiede tempo e risorse. L'utilizzo di agenti AI per automatizzare la valutazione è una soluzione promettente, ma introduce una sfida significativa per la sicurezza: come si esegue in modo sicuro il codice fornito dai partecipanti che potrebbe essere pieno di bug, dannoso o che richiede molte risorse?

L'esecuzione di codice non attendibile direttamente sulla tua infrastruttura ti espone a rischi quali:

• Inserimento di codice: script dannosi potrebbero tentare di accedere a dati sensibili o di modificarli.
• Elevazione dei privilegi: il codice potrebbe tentare di ottenere l'accesso non autorizzato ad altri sistemi o risorse di rete.
• Abuso di risorse: codice scritto male o attacchi Denial of Service potrebbero consumare CPU, memoria o larghezza di banda di rete eccessive, con conseguenze sulle altre operazioni.

Per automatizzare la valutazione degli hackathon con l'AI, abbiamo bisogno di un modo per eseguire il codice inviato in un ambiente completamente isolato dal resto del nostro sistema e da altri invii.

3. La soluzione: GKE Agent Sandbox

GKE Agent Sandbox è una funzionalità progettata appositamente per questa sfida. Consente di gestire workload isolati, stateful e a replica singola su GKE ed è ottimizzato per casi d'uso come i runtime degli agenti AI in cui il codice non attendibile deve essere eseguito in modo sicuro ed efficiente.

I vantaggi principali di Agent Sandbox includono:

• Isolamento a livello di kernel: fornisce un isolamento forte a livello di kernel per il codice non attendibile utilizzando tecnologie come gVisor, impedendo al codice di accedere al sistema host o ad altri container.
• Provisioning in meno di un secondo: offre un provisioning rapido degli ambienti sandbox (in genere < 1 secondo), fondamentale per la valutazione del codice on demand.
• Estensibilità cloud-native: sfrutta la potenza di Kubernetes e l'infrastruttura gestita di GKE.

Utilizzando Agent Sandbox, possiamo creare ambienti isolati on demand per ogni invio di hackathon. L'agente di valutazione AI può quindi istruire la sandbox dell'agente a eseguire test, compilare codice o eseguire altri passaggi di valutazione all'interno di questa sandbox sicura senza compromettere l'integrità della piattaforma complessiva. In questo modo, viene fornito un modo scalabile, sicuro ed efficiente per automatizzare la valutazione degli hackathon.

4. Prima di iniziare

Avvia Cloud Shell

Fai clic sul pulsante di seguito per avviare Google Cloud Shell, che è preconfigurato con le utilità a riga di comando per sviluppatori e cloud richieste.

Avvia Cloud Shell

Abilita API

Esegui questo comando in Cloud Shell per abilitare tutte le API Cloud di destinazione necessarie per eseguire la piattaforma:

gcloud services enable \
  container.googleapis.com \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com \
  pubsub.googleapis.com \
  aiplatform.googleapis.com \
  cloudresourcemanager.googleapis.com \
  iam.googleapis.com \
  bigquery.googleapis.com \
  bigqueryconnection.googleapis.com

Perché abilitiamo queste API: i servizi Google Cloud sono disabilitati per impostazione predefinita per impedire addebiti e accessi non autorizzati. Abilitiamo queste API specifiche per attivare l'orchestration dei container (GKE), l'archiviazione sicura dei container (Artifact Registry), il packaging delle build serverless (Cloud Build), le code di messaggistica affidabili (Pub/Sub), i servizi di modelli AI (Vertex AI), la configurazione dei progetti (Cloud Resource Manager e IAM), l'analisi dei dati serverless (BigQuery) e i binding AI a livello di database (BigQuery Connection).

5. Configura l'infrastruttura

In questo passaggio clonerai il repository di codice ed eseguirai lo script di configurazione automatica per eseguire il deployment dell'architettura cloud di destinazione e dei componenti del cluster di base.

Clona il repository

Clona il repository contenente tutti i servizi dell'applicazione, gli script di configurazione e le dichiarazioni dei manifest Kubernetes:

git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos.git
cd devrel-demos
git sparse-checkout set codelabs/ai-toolkit-lab-2/hackathon-judge
cd codelabs/ai-toolkit-lab-2/hackathon-judge

Esegui lo script di deployment

La configurazione di base delle risorse cloud, dei modelli di database e delle policy di base dei cluster Kubernetes viene automatizzata dallo script deploy.sh.

Esegui lo script:

./deploy.sh

Segui i prompt della shell interattiva per fornire configurazioni come l'ID progetto attivo e la regione di destinazione. Lo script genera automaticamente una configurazione .env locale, associa le risorse, compila le immagini container e registra l'infrastruttura di base di GKE.

Ecco le operazioni di destinazione eseguite dallo script:

1. Configurazione dell'ambiente

Lo script crea un file di configurazione .env per archiviare i parametri delle variabili di GKE, Pub/Sub, BigQuery e del progetto. L'origine di questo file compila dinamicamente tutte le definizioni dei manifest Kubernetes successive.

Perché configuriamo questo file dell'ambiente:il file .env centralizza i parametri di configurazione, garantendo che i manifest GKE che applichiamo manualmente nei passaggi successivi utilizzino impostazioni regionali, nomi di progetti e risorse identici, separando rigorosamente la configurazione dell'ambiente dal codice sorgente.

2. Google Cloud CLI e configurazione del progetto di destinazione

Lo script verifica che siano installate le utilità gcloud, bq, kubectl e envsubst, controlla lo stato di autenticazione e blocca le destinazioni di configurazione attive nel tuo progetto Google Cloud attivo.

Perché scegliamo come target il progetto attivo:l'impostazione del progetto di destinazione attivo impedisce ai comandi della CLI di influire su altri progetti nel tuo account ed esegue controlli di autenticazione pre-volo, assicurando che i comandi di configurazione non vengano interrotti a metà del deployment a causa di credenziali non valide.

3. Abilitazione delle API Cloud di destinazione

Lo script esegue un controllo idempotente per verificare e abilitare le API del servizio Google Cloud di destinazione (GKE, Artifact Registry, Cloud Build, Pub/Sub, Vertex AI, BigQuery e IAM).

Perché abilitiamo le API Google Cloud: i servizi cloud gestiti devono essere attivati prima che i relativi endpoint siano raggiungibili o che le risorse possano essere create. L'abilitazione all'inizio prepara il gateway API GCP regionale a gestire i comandi di provisioning delle risorse successivi.

4. Provisioning del repository Docker di Artifact Registry

Lo script esegue il provisioning di un repository di container Docker denominato hackathon-judge-repo nella località di destinazione selezionata.

Perché creiamo un repository Artifact Registry:i cluster GKE richiedono l'accesso sicuro ai registri dei container privati nella stessa rete regionale per eseguire il pull delle immagini delle applicazioni rapidamente. Artifact Registry fornisce un host sicuro e privato per catalogare, analizzare e archiviare le immagini container Docker.

5. Provisioning del cluster GKE Autopilot

Lo script esegue il provisioning di un cluster Google Kubernetes Engine (GKE) Autopilot denominato hackathon-judge-cluster.

Perché eseguiamo il deployment di un cluster GKE Autopilot:GKE Autopilot gestisce automaticamente il provisioning, la scalabilità, il monitoraggio dell'integrità e gli upgrade della sicurezza del sistema operativo host dei nodi. Fornisce una piattaforma container di livello di produzione per orchestrare i nostri servizi persistenti e pianifica dinamicamente sandbox di worker sicure on demand.

6. Configurazione di argomenti e sottoscrizioni Pub/Sub

Lo script esegue il provisioning degli argomenti dei messaggi (judging-tasks e judging-results) insieme ai relativi abbonamenti worker e API.

Perché implementiamo argomenti e sottoscrizioni Pub/Sub:la valutazione degli invii di codice è lenta e richiede molte risorse. L'utilizzo di un'architettura di code di messaggi disaccoppia l'API sincrona rivolta agli utenti dai nodi worker. Il backend dell'API invia i job all'argomento judging-tasks e gli agenti worker recuperano le attività man mano che sono disponibili, impedendo il blocco dell'API e fornendo funzionalità di riprova automatica.

7. Configurazione di set di dati, tabelle e connessioni AI BigQuery

Lo script crea il set di dati hackathon_judge, applica gli schemi di database SQL strutturali, carica i record iniziali e concede i ruoli AI e di archiviazione richiesti al service account di connessione BigQuery ML.

8. Attivazione delle build di container utilizzando Cloud Build

Lo script attiva la definizione cloudbuild.yaml per compilare la nostra UI React, il server Go REST, il worker ADK Python e la sandbox FastAPI, raggruppandoli in immagini container isolate taggate con lo SHA del commit Git del repository attivo e salvandoli in Artifact Registry.

9. Registrazione delle definizioni di risorse personalizzate (CRD) della sandbox dell'agente

Lo script scarica e registra le definizioni di risorse personalizzate (manifest.yaml e extensions.yaml) di Kubernetes-sigs Agent Sandbox più recenti per estendere le funzionalità di base di GKE.

Perché installiamo l'infrastruttura della sandbox dell'agente: i cluster Kubernetes standard non supportano l'allocazione di sandbox protette on demand. La registrazione delle CRD di Agent Sandbox estende il control plane di GKE, consentendo a Kubernetes di orchestrare in modo nativo i micro-container sicuri in sandbox utilizzando risorse personalizzate (come SandboxTemplates e SandboxClaims).

10. Configurazione di spazi dei nomi, service account e Workload Identity

Lo script esegue il provisioning dello spazio dei nomi hackathon-judge, registra i service account Kubernetes (KSA) e stabilisce i mapping di Workload Identity per concedere ai pod GKE le autorizzazioni Google Cloud di destinazione.

11. Deployment del router sandbox

Lo script applica il manifest k8s/sandbox_router.yaml, avviando il deployment e il servizio di Sandbox Router e attendendo che raggiungano uno stato integro.

Perché eseguiamo il deployment del router sandbox:il router sandbox è il gateway centrale del control plane interno. Espone una semplice API che l'agente worker di valutazione dell'ADK chiama per richiedere, accedere o rilasciare sandbox sicure, gestendo i mapping di routing e astraendo l'allocazione dei pod a livello di cluster dalla logica dell'applicazione.

6. Configurare Agent Sandbox Gateway, Claims e WarmPool

In questo passaggio, configurerai manualmente il gateway di rete sandbox specializzato, registrerai il modello di attestazione sandbox ed eseguirai il deployment del pool caldo sandbox per attivare il sandboxing a latenza molto bassa.

Variabili di ambiente di origine

Prima di applicare i modelli che richiedono variabili di ambiente, esegui l'origine dello script setup-env.sh per analizzare ed esportare tutte le variabili necessarie nella shell:

source ./setup-env.sh

Applica il gateway sandbox

Esegui il deployment del gateway configurato appositamente per il routing del traffico della sandbox:

kubectl apply -f k8s/sandbox-gateway.yaml

Perché implementiamo il gateway sandbox:il gateway sandbox funge da controller di ingresso sicuro e ad alte prestazioni dedicato esclusivamente al routing della sandbox. Isola la rete sandbox, fornendo una destinazione locale sicura che consente agli agenti worker di comunicare con le sandbox rivendicate senza esporre gli endpoint esternamente.

Applica il modello di rivendicazione della sandbox

Utilizza envsubst per compilare la definizione del modello sandbox con le variabili di ambiente attive e applicala:

source ./setup-env.sh
envsubst < k8s/sandbox-claim-template.yaml | kubectl apply -f -

Perché eseguiamo il deployment del modello di rivendicazione della sandbox: il modello di rivendicazione della sandbox funge da configurazione del progetto che definisce l'ambiente. Specifica l'immagine container da eseguire (preconfezionata con strumenti per sviluppatori), i parametri dell'ambiente (ID progetto GCP), le porte e i limiti delle risorse (target CPU/memoria). Configura GKE per eseguire queste istanze container utilizzando gVisor (runtime gvisor), garantendo che il codice dei partecipanti non attendibili venga eseguito in un ulteriore livello di isolamento della virtualizzazione del kernel.

Applica il WarmPool della sandbox

Applica il WarmPool della sandbox per preinizializzare le sandbox in esecuzione:

kubectl apply -f k8s/sandbox-warmpool.yaml

Verifica che le istanze di standby del pool caldo siano state avviate correttamente:

kubectl get pods -n hackathon-judge -l app=sandbox

Latenza di pre-riscaldamento:GKE potrebbe impiegare fino a un minuto per estrarre l'immagine container in sandbox e avviare le repliche pre-riscaldate. Esegui questo comando con il flag watch -w o ripetilo finché non vedi tutte e 5 le repliche nello stato Running prima di procedere con i passaggi di deployment.

Perché implementiamo Sandbox WarmPool:il provisioning, la pianificazione, il pull delle immagini e l'avvio di pod container nuovi su richiesta introducono un overhead di avvio sostanziale (tempi di avvio a freddo di oltre 30 secondi). Sandbox WarmPool gestisce un pool in standby di pod sandbox attivi e preriscaldati (5 repliche per impostazione predefinita). Quando l'agente worker richiede un ambiente di valutazione, il router sandbox alloca immediatamente un pod pre-riscaldato in esecuzione, riducendo i ritardi di avvio a velocità inferiori al secondo.

7. Esegui il deployment dei componenti dell'applicazione

Con l'infrastruttura di sandboxing sicura completamente attiva, ora puoi eseguire il deployment dell'API di backend centrale, dell'agente worker, dell'interfaccia web React e del mapping del gateway in entrata.

Esegui il deployment del backend

Esegui il deployment del backend dell'API REST dell'agente di orchestrazione:

source ./setup-env.sh
envsubst < k8s/backend.yaml | kubectl apply -f -

Esegui il deployment dell'agente

Esegui il deployment dell'agente worker di valutazione ADK:

source ./setup-env.sh
envsubst < k8s/agent.yaml | kubectl apply -f -

Esegui il deployment del frontend

Esegui il deployment dell'interfaccia utente web interattiva:

source ./setup-env.sh
envsubst < k8s/frontend.yaml | kubectl apply -f -

Configurare il gateway e il routing esterni

Esegui il deployment del gateway principale e delle route HTTP Ingress che mappano il traffico client esterno:

kubectl apply -f k8s/gateway.yaml

Perché eseguiamo il deployment del gateway Ingress esterno:il gateway esterno espone i nostri servizi utilizzando l'API Gateway di Kubernetes. Esegue il provisioning di un indirizzo IP pubblico bilanciato del carico e mappa le route in base alle regole di percorso, indirizzando le richieste API in /api/* al backend Go e mappando tutto il resto del traffico web client (/) al frontend React, proteggendo l'accesso al cluster pubblico.

Verifica implementazioni

Blocca l'esecuzione della shell e attendi che tutti e tre i deployment dei servizi principali abbiano raggiunto uno stato di implementazione pronto e integro:

kubectl rollout status deployment/backend -n hackathon-judge --timeout=300s
kubectl rollout status deployment/agent -n hackathon-judge --timeout=300s
kubectl rollout status deployment/frontend -n hackathon-judge --timeout=300s

8. Verifica e utilizza l'applicazione

Accedere all'interfaccia utente

Recupera l'indirizzo IP pubblico esterno del gateway del bilanciatore del carico principale appena sottoposto a provisioning:

Attendi il provisioning del bilanciatore del carico:il bilanciatore del carico esterno globale di Google Cloud impiega da 2 a 5 minuti per allocare le risorse IP, configurare le regole di forwarding globali e configurare il percorso di routing globale. Se la colonna ADDRESS è vuota o mostra , attendi qualche minuto ed esegui di nuovo la query.

Per monitorare lo stato del provisioning in tempo reale, esegui il comando con il flag watch (-w) e attendi finché non viene inserito un indirizzo IP pubblico nel campo ADDRESS:

kubectl get gateway -n hackathon-judge hackathon-judge-gateway -w

Se il provisioning è stato eseguito correttamente, dovresti visualizzare un output simile al seguente:

NAME                      CLASS    ADDRESS          PROGRAMMED   AGE
hackathon-judge-gateway   gke-l7   34.120.120.120   True         3m

Quando vedi un indirizzo IP pubblico valido nella colonna ADDRESS e lo stato PROGRAMMED è True, premi Ctrl+C per arrestare lo smartwatch.

Perché otteniamo lo stato del gateway:l'API Gateway gestisce l'ingresso pubblico. Il controllo dello stato del gateway restituisce l'indirizzo IP esterno pubblico con bilanciamento del carico allocato dal bilanciatore del carico esterno globale di Google Cloud al nostro cluster, che rappresenta l'indirizzo pubblico della nostra piattaforma.

Apri l'indirizzo IP pubblico allocato nel browser per caricare la dashboard dei giudici dell'hackathon.

Inviare attività

• Utilizza la UI frontend per passare alla dashboard e selezionare l'hackathon.

• In uno qualsiasi dei progetti puoi fare clic su Run Agent per avviare la valutazione dell'intero progetto da parte dell'agente in base ai criteri.

Avvio della sandbox per orologi

Monitora i pod attivi all'interno dello spazio dei nomi hackathon-judge per visualizzare un pod sandbox rivendicato e sottoposto a provisioning in modo dinamico per l'esecuzione del giudizio:

kubectl get pods -n hackathon-judge -w

Reintegro del WarmPool per progettazione:quando l'agente worker rivendica un pod sandbox pre-riscaldato dal pool, nell'elenco viene avviato un nuovo pod sandbox (transizione da Pending -> ContainerCreating -> Running). Questo comportamento è intenzionale. Il controller Agent Sandbox di GKE monitora attivamente le dimensioni del pool ed è programmato per mantenere un numero esatto di contenitori sandbox pre-riscaldati attivi (3 per impostazione predefinita). Nel momento in cui viene richiesto un container di standby, il controller pianifica immediatamente un nuovo pod preriscaldato per sostituirlo, garantendo che la piattaforma sia sempre pronta per la successiva attività di valutazione in arrivo con tempi di avvio inferiori al secondo.

Controlla i log del pod dell'agente worker per osservare la logica di valutazione passo passo del giudizio dell'ADK:

kubectl logs -l app=agent -n hackathon-judge

Perché esaminiamo i log dell'agente: l'esame dei log dell'agente worker mostra i passaggi interni dettagliati della pipeline di valutazione in tempo reale. Puoi tracciare il recupero dell'attività da parte dell'agente ADK, la richiesta di un contenitore sandbox, l'esecuzione delle destinazioni di compilazione, l'analisi dei report con Gemini e la pubblicazione dei prospetti.

9. (Facoltativo) Come funziona

Architettura di Agent Sandbox

Sebbene le funzioni BigQuery AI siano incredibili per valutare i progetti basati su testo e le rivendicazioni README, la valutazione di un progetto di ingegneria richiede la compilazione del codice, l'installazione di librerie di terze parti e l'esecuzione di suite di test reali.

L'esecuzione di codice utente non elaborato comporta enormi rischi per la sicurezza, tra cui la compromissione dell'host, le interruzioni dei container e l'accesso non autorizzato alle risorse. Il framework GKE Agent Sandbox mitiga questi rischi orchestrando carichi di lavoro sandbox isolati utilizzando la virtualizzazione gVisor (runsc).

Flusso di interazione del sistema

Il diagramma seguente mostra come comunicano i vari elementi del nostro sistema basato sugli eventi durante l'esecuzione di un giudizio sicuro in sandbox:

Come funzionano insieme gli strumenti e i componenti per il coinvolgimento

• UI front-end React: espone un'interfaccia interattiva in cui gli utenti configurano i modelli di criteri, registrano i team, inviano gli URL dei progetti e rivedono le schede di valutazione finalizzate, incluse le discrepanze complete dei file e i commenti tecnici.
• API Go REST Backend: gestisce gli endpoint API globali. Archivia le configurazioni del progetto in BigQuery e invia i job di valutazione a Pub/Sub per separare le pipeline di esecuzione di calcoli pesanti.
• Google Pub/Sub: il broker orientato ai messaggi che contiene i messaggi delle attività in modo sicuro in coda, orchestrando la comunicazione in modo asincrono tra l'API e le istanze di worker attive.
• Worker ADK Python (agente supervisore): un worker in background che recupera le attività da Pub/Sub. Sfrutta Google Agent Development Kit (ADK) per avviare un agente supervisore di alto livello, a cui viene chiesto di orchestrare la valutazione. Il supervisore richiama il suo strumento principale, evaluate_repository, per delegare i test dei comandi non elaborati.
• Router e gateway sandbox (piano di controllo GKE): un gateway di controllo interno che registra le definizioni di risorse personalizzate sandbox standard (SandboxClaims, SandboxTemplates). Coordina le reti GKE per allocare e proteggere i pod, restituendo i flussi di connessione ai client worker.
• Sandbox WarmPool: per evitare lunghi tempi di avvio dei container GKE ("avvii a freddo" di oltre 30 secondi), WarmPool mantiene attivi i pod di standby. Quando viene rivendicata una sandbox, il router la mappa immediatamente in meno di un secondo, quindi pianifica il riciclo al momento del rilascio.
• Isolamento gVisor (runsc): un kernel virtuale dello spazio utente che funge da limite di sandboxing sicuro. Intercetta le chiamate di sistema dallo spazio dei container ai kernel dei nodi GKE, garantendo che i comandi non elaborati pericolosi (come script di sistema o configurazioni di pacchetti) vengano eseguiti in un isolamento di virtualizzazione assoluto.
• Runtime sandbox FastAPI: un server API Python leggero in esecuzione all'interno del container sandbox. Espone endpoint sicuri (/execute, /upload, /download) che consentono a strumenti di lavoro esterni di manipolare i file e attivare attività della shell.
• Gemini CLI (@google/gemini-cli): uno script di agente autonomo installato all'interno della sandbox. Se attivato con il flag di runtime dell'ambiente di sviluppo (--yolo), utilizza un foglio di istruzioni di valutazione rigoroso (prompt.md) e una definizione dei criteri (criteria.md) per:
  • Analizza dinamicamente la gerarchia del codebase (utilizzando strumenti come tree o ripgrep).
  • Installare automaticamente i requisiti (tramite comandi come npm install, pip install, go build).
  • Esegui test di sviluppo reali (ad esempio npm test o pytest) per verificare la funzionalità.
  • Chiama i modelli Vertex AI (tramite le credenziali di binding di Workload Identity del container) per valutare la logica dei file, confrontare le attestazioni con il file README, rilevare funzionalità fantasma, registrare problemi di qualità e scrivere un report strutturato del prospetto in evaluation.json.
• Ambienti di sviluppo standard: raggruppa node, npm, yarn, pnpm, python, pip, uv, go, gh, git, tree, ripgrep e playwright nell'immagine container sandbox, fornendo al sub-agente autonomo un workspace di test completo.

Sicurezza di Workload Identity in azione: nota come al service account GKE sandbox (hackathon-judge-sandbox-sa) sia stata concessa l'autorizzazione IAM standard roles/aiplatform.user durante la configurazione dell'infrastruttura. Quando la CLI Gemini all'interno del pod sandbox richiede risposte del modello da Vertex AI, Workload Identity di GKE automatizza la generazione delle chiavi e il controllo delle credenziali in background. Il container non memorizza mai chiavi API statiche o credenziali cloud hardcoded, mantenendo automaticamente le linee guida di sicurezza di primo livello.

10. Elimina

Per evitare addebiti continui al tuo account Google Cloud, elimina le risorse create durante questo codelab.

./destroy.sh

Perché liberiamo spazio dalle risorse: Google Cloud fattura in base a un modello di utilizzo delle risorse. Le risorse attive come i cluster GKE Autopilot, i bilanciatori del carico di rete e i dischi permanenti comportano addebiti continui anche quando sono inattive. L'esecuzione di questo passaggio elimina lo spazio dei nomi del cluster per cancellare gli oggetti Kubernetes ed elimina l'host del cluster GKE Autopilot stesso per interrompere immediatamente tutti gli addebiti di fatturazione sottostanti.

11. Complimenti

Complimenti! Hai eseguito il deployment dell'applicazione Hackathon Judge con Agent Sandbox su GKE.

Hai implementato una piattaforma AI moderna, sicura e basata sugli eventi in grado di testare e valutare invii di codebase non attendibili in base a vincoli di sicurezza containerizzati isolati.

Cosa hai imparato

• Infrastruttura GKE: come eseguire il provisioning di GKE Autopilot e dei servizi Google Cloud di supporto come Pub/Sub e BigQuery.
• Configurazione di Agent Sandbox: come configurare le definizioni di risorse personalizzate, i modelli sandbox, le richieste sandbox e i pool di preavvio sandbox ad alto rendimento.
• Deployment dei microservizi: come configurare i binding di Workload Identity ed eseguire il deployment di un'architettura di microservizi multi-componente (Frontend React, REST Go, Worker ADK Agent e Isolated Sandbox).
• Sandboxing sicuro: come utilizzare i container virtualizzati gVisor per eseguire in modo sicuro comandi di terze parti non attendibili sui nodi GKE.

Passaggi successivi

• Esplora la documentazione di Agent Sandbox.
• Scopri di più sulle funzionalità di GKE Autopilot.
• Consulta la documentazione di Agent Platform.

Documenti di riferimento

• Specifiche dell'API Kubernetes Gateway
• Runtime di limitazione tramite sandbox gVisor