Informazioni sull'identità dell'agente per GKE

I carichi di lavoro degli agenti spesso richiedono misure difensive, controllo dell'accesso e flussi di lavoro di autenticazione diversi rispetto ad altri tipi di carichi di lavoro. Puoi utilizzare Agent Identity per assegnare a ogni agente un'identità attestata, di breve durata e per pod. Questa identità ti aiuta a identificare i workload degli agenti e a monitorare e gestire le loro attività su Google Cloud. Questo documento descrive il funzionamento dell'identità dell'agente in Google Kubernetes Engine (GKE), inclusa l'integrazione con altri prodottiGoogle Cloud , i tipi di autenticazione che gli agenti possono utilizzare e come governare i workload utilizzando queste identità.

Questo documento è destinato agli amministratori della piattaforma e agli esperti di sicurezza che vogliono migliorare la sicurezza degli agenti eseguiti sui cluster GKE integrandoli con prodotti e servizi Google Cloud .

Dovresti già avere familiarità con i seguenti argomenti:

Che cos'è l'identità dell'agente?

Google Cloud fornisce vari tipi di identità per i tuoi workload, ognuno dei quali è destinato a un insieme specifico di casi d'uso e tipi di workload. L'identità dell'agente è un tipo di identità progettato per i workload degli agenti AI. Un agente che utilizza Agent Identity riceve un'identità univoca basata sullo standard SPIFFE. Questa identità è vincolata al ciclo di vita dell'agente, identifica il workload come agente ed è riconosciuta dai vari servizi di Gemini Enterprise Agent Platform, come Agent Registry e Agent Gateway. Puoi monitorare e gestire un workload con un'identità agente in tutti i servizi a cui accede il workload, indipendentemente da dove viene eseguito. Un workload che utilizza l'identità dell'agente può autenticarsi su server MCP, risorse all'interno e all'esterno di Google Cloud, altri agenti ed endpoint utilizzando la propria identità o per conto di un utente finale. Per saperne di più sull'identità dell'agente, consulta Panoramica dell'identità dell'agente.

Puoi utilizzare l'identità dell'agente per migliorare la sicurezza e la governance degli agenti AI che implementi nei cluster GKE e per abilitare flussi di lavoro specifici per i tuoi agenti, ad esempio:

  • Integra gli agenti su GKE con prodotti come Agent Registry e Agent Gateway.
  • Gestisci i ruoli per i carichi di lavoro degli agenti in progetti, cartelle o organizzazioni nei criteri Identity and Access Management (IAM).
  • Ridurre l'impatto degli agenti compromessi sui nodi e sugli altri pod del cluster.
  • Configura vari workflow di autenticazione, ad esempio gli agenti che agiscono per conto degli utenti finali, utilizzando il gestore di autenticazione di Agent Identity.

Confronto con la federazione delle identità per i workload per GKE

Sia Agent Identity sia Workload Identity Federation for GKE forniscono modi per assegnare identità ai workload. L'identità dell'agente è progettata per il modello di minaccia e i requisiti specifici che si applicano agli agenti AI, il che comporta varie differenze funzionali. La seguente tabella fornisce un confronto generale di queste differenze:

Agent Identity Workload Identity Federation for GKE
I token di accesso all'identità dell'agente possono essere associati in modo crittografico ai certificati X.509 per pod. Un token di accesso vincolato richiede una connessione mTLS e non funziona se utilizzato al di fuori del pod originale. I token di accesso federato non sono associati crittograficamente alle identità dei pod, funzionano su connessioni non mTLS e possono essere utilizzati al di fuori del pod originale.
Si integra con il gestore di autenticazione di Agent Identity per supportare i workflow OAuth e utilizzare le credenziali di terze parti senza gestione manuale delle credenziali. Richiede l'implementazione manuale dei flussi di lavoro OAuth e la gestione delle credenziali di terze parti durante l'autenticazione a strumenti e servizi esterni.
Funziona bene per i workload autonomi come gli agenti AI. Funziona bene per microservizi deterministici come server web, API e job batch.
Richiede la versione 1.37.0-gke.3503000 di GKE o versioni successive. Disponibile in tutte le versioni di GKE.
I token di accesso dell'identità dell'agente vincolato utilizzano sempre l'ambito di accesso https://www.googleapis.com/auth/cloud-platform. Gli ambiti personalizzati non sono supportati. I token di accesso federati supportano ambiti di accesso personalizzati.
Le applicazioni possono ottenere token ID identità agente per l'autenticazione diretta ad altri workload o servizi downstream. Le applicazioni non possono ottenere token ID a meno che il service account Kubernetes non sia configurato per impersonare unaccount di serviziot IAM.

Integrazione con Agent Platform

Gemini Enterprise Agent Platform include più prodotti e servizi progettati per creare, gestire e utilizzare gli agenti su larga scala. Se esegui workload degli agenti su GKE, puoi utilizzare i prodotti Agent Platform assegnando identità degli agenti ai workload e registrando i workload come agenti in Agent Registry. Per integrare e utilizzare i servizi della piattaforma Agent con i tuoi agenti GKE, gli operatori delle applicazioni aggiungono annotazioni ed etichette alle specifiche Kubernetes dei carichi di lavoro dell'agente. A parte la verifica che Workload Identity Federation for GKE sia abilitata, non devi apportare modifiche alla configurazione del cluster o del pool di nodi. Puoi quindi gestire e controllare i tuoi agenti GKE nello stesso modo in cui controlli un agente eseguito su Agent Runtime o Cloud Run.

La registrazione in Agent Registry contribuisce anche a prevenire potenziali interruzioni quando sposti i progetti tra le organizzazioni. Durante lo spostamento di un progetto, Agent Registry verifica se degli agenti utilizzano un'identità agente basata sul dominio di attendibilità a livello di organizzazione, che cambierebbe dopo lo spostamento. Se è in uso un'identità agente a livello di organizzazione, lo spostamento del progetto viene bloccato. Questo controllo viene eseguito solo con i deployment che registri in Agent Registry. Il controllo non viene eseguito con altri controller dei workload o pod statici.

Come funziona in GKE

In GKE, l'identità dell'agente utilizza concetti come il server di metadati GKE e i pool di identità, in modo simile a Workload Identity Federation for GKE. Per utilizzare l'identità dell'agente, devi anche abilitare Workload Identity Federation for GKE nel cluster. Google Cloud crea automaticamente un pool di identità dell'agente a livello di progetto o organizzazione. Il pool di identità dell'agente è un dominio di attendibilità SPIFFE ed è la radice di attendibilità per le identità e le credenziali dell'agente. Gli sviluppatori di applicazioni possono richiedere un'identità dell'agente per il proprio agente aggiungendo annotazioni ed etichette alla specifica del pod. Quando il workload viene eseguito il deployment in un cluster, GKE assegna le seguenti credenziali al workload:

  • Un'identità SPIFFE che identifica il workload. Tutti i pod in un carico di lavoro gestito, ad esempio un deployment, condividono l'ID SPIFFE del carico di lavoro. L'ID SPIFFE identifica l'agente in tutti i servizi Google Cloud . Puoi monitorare qualsiasi azione eseguita dai pod, sia come agente sia per conto di un utente finale, utilizzando l'ID SPIFFE. L'ID SPIFFE ha la seguente sintassi:

    spiffe://TRUST_DOMAIN/resources/container/projects/PROJECT_NUMBER/locations/CONTROL_PLANE_LOCATION/clusters/CLUSTER_NAME/ns/NAMESPACE/sa/SERVICEACCOUNT_NAME

    Questa stringa ID ha i seguenti attributi:

    • TRUST_DOMAIN: il dominio di attendibilità SPIFFE, che ha uno dei seguenti valori, a seconda che il progetto che contiene il cluster si trovi o meno in un'organizzazione:
      • Progetti che si trovano in un'organizzazione: agents.global.org-ORGANIZATION_ID.system.id.goog, dove ORGANIZATION_ID è l'ID dell'organizzazione.
      • Progetti che non fanno parte di un'organizzazione: agents.global.proj-PROJECT_NUMBER.system.id.goog, dove PROJECT_NUMBER è il numero di progetto del progetto cluster.
    • PROJECT_NUMBER: il numero del progetto cluster.
    • CONTROL_PLANE_LOCATION: la regione o la zona in cui si trova il control plane del cluster.
    • CLUSTER_NAME: il nome del cluster in cui si trova il pod.
    • NAMESPACE: il nome dello spazio dei nomi Kubernetes in cui si trova il pod.
    • SERVICEACCOUNT_NAME: il nome del ServiceAccount Kubernetes assegnato al pod.

  • Un bundle di credenziali dell'identità dell'agente (x509.credential-bundle.private-key.pem) montato come volume in ogni pod e che può essere utilizzato per l'autenticazione mTLS alle API Google Cloud . Questo file include le seguenti credenziali:

    • Una catena di certificati X.509 che include l'ID SPIFFE per il workload dell'agente come parametro Nome alternativo del soggetto (SAN) e scade tra 24 ore. La catena di certificati viene utilizzata per ottenere token di accesso vincolati e token ID per l'autenticazione ad altri servizi.
    • Una chiave privata che il processo kubelet crea automaticamente per ogni pod. La chiave lega crittograficamente il certificato X.509 di un pod al pod. Questa chiave dimostra che il pod che ha effettuato una richiesta è proprietario del certificato X.509 utilizzato per stabilire la connessione TLS.

  • Un bundle di attendibilità della CA radice (TRUST_DOMAIN.spiffe-trust-bundle.pem) montato come volume in ogni pod e che può essere utilizzato per configurare l'autenticazione mTLS tra gli agenti che utilizzano lo stesso dominio di attendibilità. Durante l'handshake mTLS, un agente utilizza il bundle di attendibilità della CA radice per convalidare la catena di certificati presentata da un agente peer.

Configurazione a livello di workload

Per assegnare un'identità agente e credenziali per pod a un workload, GKE cerca le seguenti annotazioni nella specifica del pod:

  • iam.gke.io/identity: "spiffe://TRUST_DOMAIN/*": GKE utilizza questa annotazione per assegnare ai pod un ID SPIFFE dal dominio di attendibilità corrispondente.

  • iam.gke.io/inject-podcertificates: "true": GKE utilizza questa annotazione per aggiungere il bundle di credenziali dell'identità dell'agente e il bundle di attendibilità del cluster a ogni pod nel workload. Se questa annotazione viene omessa, non puoi ottenere token di accesso associati a pod specifici. Le credenziali inserite vengono utilizzate per l'autenticazione mTLS dai tuoi pod a qualsiasi API o agenti peerGoogle Cloud .

Inoltre, Agent Registry utilizza la seguente etichetta e annotazione per registrare automaticamente gli agenti GKE:

  • Etichetta registry.gke.io/functional-type: "AGENT": identifica il carico di lavoro come agente AI e aggiunge l'agente ad Agent Registry. Questa etichetta è supportata solo dai deployment e deve essere specificata nel campo metadata.labels del manifest del deployment.
  • Annotazione iam.gke.io/spiffe-identity-type: "agent-identity": indica che l'agente utilizza Agent Identity. Questa annotazione è specificata nella specifica del pod. Se l'etichetta registry.gke.io/functional-type: "AGENT" è specificata per un deployment, questa annotazione è obbligatoria nella specifica del pod.

Per integrare gli agenti GKE con Agent Platform, registra i tuoi carichi di lavoro con Agent Registry oltre a utilizzare l'identità dell'agente. Valuta la possibilità di imporre la registrazione dei workload degli agenti o automatizzare la registrazione nella pipeline di deployment.

Token di accesso per gli agenti

In GKE, ogni pod che utilizza l'identità dell'agente riceve un bundle di credenziali univoco che contiene il certificato X.509 e la chiave privata del pod, che non esce dal pod. Per accedere a qualsiasi Google Cloud API o servizio esterno, un pod agente in un cluster GKE richiede un token di accesso con identità agente dal server metadati GKE in esecuzione su ogni nodo. Il pod utilizza il token di accesso all'identità dell'agente per autenticarsi come identità dell'agente.

Il token di accesso può essere associato o non associato, come segue:

  • Token di accesso vincolato: vincolato crittograficamente al certificato X.509 del pod e può essere utilizzato solo su connessioni mTLS autenticate utilizzando quel certificato X.509. Qualsiasi richiesta di token di accesso che includa il certificato X.509 nel payload genera un token vincolato.
  • Token di accesso non associato: non associato crittograficamente a un pod specifico e può essere utilizzato su connessioni non mTLS. I token di accesso non associati sono più vulnerabili agli attacchi di replay dei token, perché un token compromesso può essere utilizzato da un pod diverso.

Gli agenti utilizzano i token di accesso associati o non associati per autenticare le richieste alle APIGoogle Cloud . Gli amministratori delle identità possono controllare l'accesso di un agente specificando l'identificatore principale del token di accesso all'identità dell'agente nelle policy IAM, come descritto in Controllare l'accesso alle Google Cloud risorse per gli agenti.

Se i pod hanno l'annotazione iam.gke.io/inject-podcertificates: "true", le librerie client di Google Cloud e le librerie di autenticazione di Google utilizzano le credenziali predefinite dell'applicazione (ADC) per ottenere automaticamente un token di accesso all'identità dell'agente vincolato per i pod. Questo processo automatico potrebbe non verificarsi in tutte le librerie o in tutti i linguaggi di programmazione. Per richiedere token di accesso non associati, gli sviluppatori utilizzano uno dei seguenti metodi:

  • Specifica l'annotazione iam.gke.io/inject-podcertificates: "true" e imposta la variabile di ambiente GOOGLE_API_ENABLE_RUNTIME_BOUND_TOKEN su un valore di false nella specifica del pod. GKE aggiunge il bundle di credenziali X.509 al pod, ma la variabile di ambiente fa sì che ADC ottenga token di accesso non associati.

    Questo metodo consente ai pod di continuare a stabilire connessioni mTLS con altri carichi di lavoro utilizzando i certificati e i token di accesso non associati per accedere alle API Google Cloud .

  • Non specificare l'annotazione iam.gke.io/inject-podcertificates: "true" nella specifica del pod. GKE non aggiunge il bundle di credenziali X.509 al pod, quindi ADC riceve token di accesso non associati per i pod.

  • Invia una richiesta HTTP GET diretta all'endpoint token del server di metadati GKE, che restituisce un token di accesso non associato.

Workflow di autenticazione per gli agenti

A differenza dei carichi di lavoro non agent, gli agent potrebbero dover eseguire l'autenticazione ai servizi per conto di un utente finale o come identità dell'agente, a seconda dell'attività che l'agente sta tentando di eseguire. L'identità dell'agente supporta l'autenticazione ai seguenti tipi di risorse utilizzando varie credenziali e modelli di autenticazione:

  • APIGoogle Cloud
  • Strumenti e servizi esterni
  • Autenticazione da agente ad agente

Autenticazione alle Google Cloud API

Un agente può utilizzare la propria identità per autenticarsi alle Google Cloud API, ad esempio a BigQuery o alla piattaforma Agent. Per l'autenticazione, il pod riceve un token di accesso dell'identità dell'agente dal server metadati GKE sul nodo. Questo token di accesso può essere associato al certificato X.509 del pod, il che significa che il token di accesso può essere utilizzato solo tramite una connessione mTLS autenticata utilizzando il certificato X.509.

Se la tua applicazione utilizza la versione 2.61.0 o successive della libreria di autenticazione Python google-auth, le Credenziali predefinite dell'applicazione (ADC) richiedono automaticamente token di accesso associati per i pod che hanno il bundle di credenziali di identità dell'agente. Se utilizzi le librerie client di Cloud per Python, assicurati di utilizzare una versione che includa la versione 2.61.0 o successive della libreria google-auth. Per altri linguaggi di programmazione o per versioni della libreria Python google-auth precedenti alla 2.61.0, richiedi invece token di accesso non associati.

Se ricevi un token di accesso vincolato, devi utilizzare il certificato X.509 del pod per stabilire una connessione mTLS con l'endpoint mTLS dell'API di destinazione. Se ricevi un token di accesso non associato, puoi utilizzarlo nelle richieste all'endpoint non mTLS di questa API.

Per configurare il codice dell'applicazione in modo da ottenere token di accesso associati o non associati utilizzando questi metodi, consulta Autenticarsi utilizzando un'identità agente in GKE.

Se sei un amministratore della piattaforma o un amministratore della sicurezza, non devi configurare un'autenticazione aggiuntiva per gli agenti che si autenticano alle APIGoogle Cloud . Puoi controllare l'accesso alle risorse utilizzando i criteri IAM, come descritto in Controllare l'accesso alle Google Cloud risorse per gli agenti.

Autenticazione dell'agente per i servizi esterni

Gli agenti spesso devono accedere a strumenti e servizi esterni utilizzando credenziali specifiche, come chiavi API o token OAuth. L'agente potrebbe dover autenticarsi come propria identità o per conto di un utente finale. Puoi fornire agli agenti credenziali specifiche utilizzando gestore di autenticazione di Agent Identity (anteprima). Auth Manager centralizza l'acquisizione delle credenziali e la configurazione del flusso di lavoro di autenticazione per gli agenti che esegui su Google Cloud.

In Auth Manager, configuri i provider di autenticazione per gestire flussi di lavoro di autenticazione specifici. Quando un agente in GKE deve autenticarsi utilizzando una credenziale specifica, il pod utilizza il token di accesso dell'identità dell'agente per autenticarsi con Auth Manager. Il provider di autenticazione gestisce eventuali passaggi di autenticazione aggiuntivi e restituisce la credenziale richiesta al pod. Il gestore di autenticazione scambia le credenziali esterne con token di accesso a breve durata, in modo che i token di aggiornamento a lunga durata e gli API secret non vengano archiviati nel contenitore dell'agente.

Puoi utilizzare Auth Manager per i seguenti casi d'uso, ognuno dei quali prevede una configurazione specifica in Auth Manager e nel codice dell'applicazione:

  • Accedere a servizi esterni per conto di un utente finale.
  • Accedere a servizi esterni con la propria identità.
  • Accedere alle API utilizzando una chiave API.

Puoi monitorare e revocare le credenziali create da Auth Manager. Puoi anche monitorare le credenziali utilizzate da agenti specifici, perché l'agente si autentica nel gestore dell'autenticazione utilizzando il token di accesso all'identità dell'agente. Le sezioni seguenti descrivono i casi d'uso per Auth Manager e i modelli di autenticazione corrispondenti. A seconda del modello di autenticazione che utilizzi, tu e gli sviluppatori delle tue applicazioni dovete apportare modifiche specifiche al codice dell'agente e alle applicazioni lato client.

Accesso a servizi esterni per conto di un utente finale

Un utente finale potrebbe chiedere a un agente di eseguire determinate azioni per suo conto, ad esempio scrivere messaggi in un canale Slack o aprire una richiesta di pull in un repository GitHub. In questi scenari, l'utente delega la propria autorità all'agente acconsentendo esplicitamente che agisca per suo conto. Per configurare il consenso dell'utente e il recupero delle credenziali, utilizza OAuth a tre vie, che prevede i seguenti passaggi:

  1. Il provider di autenticazione reindirizza l'utente per l'autenticazione al servizio esterno.
  2. L'utente accede e approva l'accesso di cui ha bisogno l'agente.
  3. Il servizio esterno restituisce una credenziale al provider di autenticazione.

Per configurare OAuth a tre passaggi per un agente in esecuzione su GKE, l'amministratore della piattaforma e lo sviluppatore dell'applicazione seguono questi passaggi:

  1. L'amministratore della piattaforma configura il provider di autenticazione:
    1. Crea un provider di autenticazione OAuth a tre vie in Auth Manager.
    2. Configura il provider di autenticazione in modo che reindirizzi al server di autorizzazione di terze parti.
    3. Configura il servizio di terze parti in modo che invii il token di accesso utente al provider di autenticazione.
    4. Autorizza l'agente ad accedere al provider di autenticazione.
  2. Lo sviluppatore dell'applicazione modifica l'applicazione:
    1. Modifica il codice dell'agente per l'autenticazione utilizzando il provider di autenticazione.
    2. Modifica il codice dell'applicazione lato client per gestire l'accesso, il reindirizzamento e la ripresa della conversazione dell'utente.

Per saperne di più su come configurare il fornitore di autenticazione e modificare le applicazioni lato agente e lato client, vedi Autenticarsi utilizzando OAuth a tre vie con Auth Manager.

Accesso a servizi esterni come identità dell'agente

Un agente potrebbe dover accedere a servizi esterni come ServiceNow o Salesforce utilizzando la propria identità. Ad esempio, un agente di gestione dell'inventario potrebbe monitorare i dati di vendita e ordinare l'inventario per evitare problemi di scorte durante i periodi di picco delle vendite. In questi scenari, utilizzi OAuth a due vie, che prevede i seguenti passaggi:

  1. Il gestore di autenticazione richiede un token di accesso al servizio esterno.
  2. Il servizio esterno convalida la richiesta e restituisce il token di accesso al gestore dell'autenticazione.

Per configurare OAuth a due chiamate per un agente in esecuzione su GKE, devi:

  1. L'amministratore della piattaforma configura il provider di autenticazione:
    1. Ottieni un ID client OAuth, un client secret e un endpoint del token dal servizio esterno.
    2. Crea un provider di autenticazione OAuth a 2 passaggi in Auth Manager che contenga le informazioni OAuth del servizio esterno.
    3. Autorizza l'agente ad accedere al provider di autenticazione.
  2. Lo sviluppatore dell'applicazione modifica il codice dell'agente per eseguire l'autenticazione utilizzando il provider di autenticazione.

Per saperne di più su come configurare il fornitore di autenticazione e modificare il codice dell'agente, consulta Autenticarsi utilizzando OAuth a due vie con Auth Manager.

Accesso alle API utilizzando una chiave API

Puoi memorizzare le chiavi API in Auth Manager affinché gli agenti le utilizzino per autenticarsi alle API esterne. Sebbene tu possa archiviare le chiavi API in altri vault come Secret Manager, il metodo di gestione dell'autenticazione ti consente di monitorare e gestire l'accesso dell'agente alle chiavi API in una posizione centrale. Per archiviare e utilizzare le chiavi API in auth manager, procedi nel seguente modo:

  1. L'amministratore della piattaforma configura il provider di autenticazione:
    1. Crea un provider di autenticazione con chiave API in Auth Manager.
    2. Genera e memorizza la chiave API nel provider di autenticazione.
    3. Autorizza l'agente ad accedere al provider di autenticazione.
  2. Modifica il codice dell'agente per l'autenticazione utilizzando il provider di autenticazione.

Per saperne di più, consulta Autenticati utilizzando la chiave API con Auth Manager.

Autenticazione da agente ad agente

Questa sezione descrive un flusso di lavoro di autenticazione avanzato. Dovresti già avere familiarità con i seguenti argomenti:

  • Token web JSON (JWT): i token ID identità dell'agente sono JWT firmati.
  • Intestazioni JSON Object Signing and Encryption (JOSE): i token ID hanno un'intestazione JOSE che descrive l'algoritmo e la chiave di firma per il token ID.
  • Chiavi web JSON (JWK): le JWK vengono utilizzate per firmare i token ID. Le JWK pubbliche per un pool di identità dell'agente vengono pubblicate come set di chiavi web JSON (JWKS). Utilizzi queste chiavi pubbliche per convalidare i token ID in entrata da altri agenti.

Nelle architetture multi-agente, gli agenti collaborano spesso richiamando direttamente agenti peer o servizi downstream. Puoi stabilire direttamente la comunicazione tra i workload degli agenti utilizzando un token di identità dell'agente, ovvero un JWT firmato che puoi ottenere dal server metadati GKE. Per autenticare una connessione tra i servizi dell'agente, gli sviluppatori di applicazioni procedono nel seguente modo:

  1. Ottieni un token ID identità agente dal server di metadati GKE per l'agente chiamante. Questo token ID deve impostare l'attestazione aud sull'endpoint dell'agente ricevente.
  2. Includi il token ID nell'intestazione della richiesta Authorization: Bearer della richiesta HTTP.
  3. Nell'agente ricevente, convalida il token ID in entrata utilizzando le chiavi JWK pubbliche per il pool di identità dell'agente e i vari parametri di intestazione e corpo nel token ID.

Per saperne di più su come richiedere, utilizzare e convalidare i token ID nel codice dell'applicazione, consulta Autenticarsi presso altri agenti.

L'autenticazione da agente ad agente non richiede Google Cloud configurazione aggiuntiva da parte di un amministratore della piattaforma, perché questo workflow bypassa i controlli di autorizzazione IAM. Gli agenti, invece, comunicano direttamente tra loro e autorizzano le azioni in base alle identità degli agenti.

Controlla l'accesso alle risorse Google Cloud per gli agenti

Gli amministratori della sicurezza possono controllare a quali risorse può accedere un agente utilizzando policy IAM che fanno riferimento all'identificatore principale dell'agente. Per controllare l'accesso alle risorse per un agente in esecuzione su GKE e con un'identità dell'agente, includi uno dei seguenti identificatori dell'entità nella policy IAM:

  • Tutti gli agenti in un dominio di attendibilità specifico:

    principalSet://TRUST_DOMAIN/*

    In questo identificatore, TRUST_DOMAIN è il dominio attendibile per la gerarchia delle risorse, che dipende dal fatto che l'agente si trovi in un progetto che fa parte di un'organizzazione:

    • Progetti che si trovano in un'organizzazione: agents.global.org-ORGANIZATION_ID.system.id.goog, dove ORGANIZATION_ID è l'ID dell'organizzazione.
    • Progetti che non si trovano in un'organizzazione: agents.global.proj-PROJECT_NUMBER.system.id.goog, dove PROJECT_NUMBER è il numero di progetto del progetto cluster.

  • Un singolo agente in un dominio di attendibilità:

    principal://TRUST_DOMAIN/resources/container/projects/PROJECT_NUMBER/locations/CONTROL_PLANE_LOCATION/clusters/CLUSTER_NAME/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME

    In questo identificatore, i seguenti parametri identificano l'agente specifico:

    • PROJECT_NUMBER: il numero del progetto del cluster.
    • CONTROL_PLANE_LOCATION: la regione o la zona del control plane del cluster.
    • CLUSTER_NAME: il nome del cluster in cui si trova l'agente.
    • NAMESPACE_NAME: il nome dello spazio dei nomi Kubernetes in cui si trova l'agente.
    • SERVICEACCOUNT_NAME: il nome del service account Kubernetes utilizzato dal workload dell'agente.

Per saperne di più su come trovare gli identificatori dei principal per gli agenti GKE e gestire l'accesso, consulta Gestire l'accesso alle Google Cloud API per gli agenti.

L'identità dell'agente supporta tutti i tipi di policy IAM, come le policy di autorizzazione, le policy di negazione e le policy sul confine di accesso dell'entità (PAB). Per gestire l'accesso per un agente in un cluster GKE che utilizza l'identità dell'agente, includi l'identificatore dell'entità dell'agente nel tipo di policy corrispondente. Per ulteriori informazioni su come configurare ogni tipo di policy IAM, consulta i seguenti argomenti:

Visualizzare e gestire gli agenti su Google Cloud

Se gli sviluppatori di applicazioni registrano i propri agenti in Agent Registry, puoi visualizzare gli agenti GKE insieme agli altri agenti che esegui in Google Cloud. Agent Registry mostra l'identità SPIFFE dell'agente, dove viene eseguito e qualsiasi informazione aggiuntiva sull'agente. Tutte le richieste API autenticate utilizzando Agent Identity generano audit log di Agent Registry. A seconda del flusso di lavoro di autenticazione utilizzato dall'agente, Cloud Audit Logs fornisce le seguenti informazioni:

  • Autenticazione tramite l'identità dell'agente: i log di controllo generati includono l'identificatore principale dell'agente, che puoi utilizzare per trovare il cluster, lo spazio dei nomi e ServiceAccount dell'agente.
  • Operazioni delegate per conto degli utenti finali: i log di controllo generati includono informazioni sull'utente finale che ha autorizzato l'azione e l'ID SPIFFE dell'agente che ha eseguito la chiamata. Questa associazione di identità nei log di controllo ti aiuta a verificare che l'utente finale abbia autorizzato azioni specifiche.

Oltre a Cloud Audit Logs, gli sviluppatori di applicazioni possono configurare i carichi di lavoro degli agenti per emettere tracce, log e metriche che diventano visibili in Google Cloud Observability. Per saperne di più su come configurare i workload, consulta i seguenti documenti:

Migliorare la sicurezza degli agenti GKE

Gli amministratori della sicurezza possono gestire le misure di sicurezza specifiche per gli agenti separatamente dai vincoli per altri tipi di workload facendo riferimento alle identità degli agenti. Prendi in considerazione le seguenti misure difensive quando esegui gli agenti:

Limitazioni

  • Puoi registrare automaticamente solo i deployment in Agent Registry. Altri controller dei carichi di lavoro e pod statici non supportano la registrazione automatica.
  • I token di accesso con identità dell'agente vincolata utilizzano solo l'ambito OAuth https://www.googleapis.com/auth/cloud-platform. Non puoi specificare un ambito diverso per i token di accesso vincolati.
  • Il recupero automatico dei token di accesso o token ID associati è supportato solo nelle applicazioni Python che utilizzano la versione 2.61.0 o successive della libreria google-auth. Se utilizzi le librerie client di Cloud per Python, devi utilizzare una versione che includa la versione 2.61.0 o successive della libreria google-auth.
  • Alcune librerie client Cloud potrebbero non instradare automaticamente le tue richieste agli endpoint mTLS.
  • Per l'autenticazione da agente ad agente, puoi utilizzare token ID vincolati solo per l'autenticazione tra agenti che si trovano nello stesso dominio di attendibilità dell'identità dell'agente.

Passaggi successivi