Acerca de la identidad del agente para GKE

Las cargas de trabajo de los agentes suelen requerir diferentes medidas de defensa, control de acceso y flujos de trabajo de autenticación que otros tipos de cargas de trabajo. Puedes usar Identidad del agente para otorgar a cada agente una identidad atestada, de corta duración y por Pod. Esta identidad te ayuda a identificar las cargas de trabajo del agente y a hacer un seguimiento de lo que hacen esas cargas de trabajo en Google Cloud, así como a administrarlo. En este documento, se describe cómo funciona la identidad del agente en Google Kubernetes Engine (GKE), incluida la forma de integrarla con otros productos deGoogle Cloud , los tipos de autenticación que pueden usar tus agentes y cómo controlar tus cargas de trabajo con estas identidades.

Este documento está dirigido a los administradores de plataformas y los ingenieros de seguridad que desean mejorar la seguridad de los agentes que se ejecutan en clústeres de GKE mientras integran los agentes con Google Cloud productos y servicios.

Debes tener conocimientos generales sobre los siguientes temas:

¿Qué es la identidad del agente?

Google Cloud proporciona varios tipos de identidades para tus cargas de trabajo, cada uno de los cuales está diseñado para un conjunto específico de casos de uso y tipos de cargas de trabajo. La identidad del agente es un tipo de identidad diseñado para cargas de trabajo de agentes de IA. Un agente que usa la identidad del agente obtiene una identidad única basada en el estándar de SPIFFE. Esta identidad está vinculada al ciclo de vida del agente, identifica la carga de trabajo como un agente y es reconocida por los distintos servicios de Gemini Enterprise Agent Platform, como Agent Registry y Agent Gateway. Puedes hacer un seguimiento de una carga de trabajo que tiene una identidad de agente y administrarla en todos los servicios a los que accede la carga de trabajo, independientemente de dónde se ejecute. Una carga de trabajo que usa Agent Identity puede autenticarse en servidores de MCP, recursos dentro y fuera de Google Cloud, otros agentes y extremos con su propia identidad o en nombre de un usuario final. Para obtener más información sobre la identidad de agentes, consulta la descripción general de la identidad de agentes.

Puedes usar la identidad del agente para mejorar la seguridad y la administración de los agentes de IA que implementas en los clústeres de GKE, y para habilitar flujos de trabajo específicos para tus agentes, como los siguientes:

  • Integra agentes en GKE con productos como Agent Registry y Agent Gateway.
  • Administrar roles para cargas de trabajo de agentes en proyectos, carpetas u organizaciones en políticas de Identity and Access Management (IAM)
  • Reducir el impacto de los agentes vulnerados en los nodos y otros Pods del clúster
  • Configura varios flujos de trabajo de autenticación, como agentes que actúan en nombre de usuarios finales, con el administrador de autenticación de identidad del agente.

Comparación con Workload Identity Federation for GKE

Tanto la identidad del agente como la federación de identidades para cargas de trabajo para GKE proporcionan formas de asignar identidades a las cargas de trabajo. La identidad del agente está diseñada para el modelo de amenazas y los requisitos específicos que se aplican a los agentes de IA, lo que genera varias diferencias funcionales. En la siguiente tabla, se proporciona una comparación general de estas diferencias:

Agent Identity Workload Identity Federation for GKE
Los tokens de acceso de identidad del agente se pueden vincular criptográficamente a certificados X.509 por Pod. Un token de acceso vinculado requiere una conexión mTLS y no funciona cuando se usa fuera del Pod original. Los tokens de acceso federado no están vinculados de forma criptográfica a las identidades de Pod, funcionan a través de conexiones que no son de mTLS y se pueden usar fuera del Pod original.
Se integra con el administrador de autenticación de Agent Identity para admitir flujos de trabajo de OAuth y usar credenciales de terceros sin administración manual de credenciales. Requiere la implementación manual de flujos de trabajo de OAuth y la administración de credenciales de terceros cuando se realiza la autenticación en herramientas y servicios externos.
Funciona bien para cargas de trabajo autónomas, como los agentes de IA. Funciona bien para microservicios determinísticos, como servidores web, APIs y trabajos por lotes.
Requiere la versión 1.37.0-gke.3503000 de GKE o una posterior. Disponible en todas las versiones de GKE.
Los tokens de acceso de identidad del agente vinculados siempre usan el permiso de acceso https://www.googleapis.com/auth/cloud-platform. No se admiten los permisos personalizados. Los tokens de acceso federado admiten permisos de acceso personalizados.
Las aplicaciones pueden obtener tokens de ID de identidad del agente para autenticarse directamente en otras cargas de trabajo o servicios descendentes. Las aplicaciones no pueden obtener tokens de ID, a menos que la cuenta de servicio de Kubernetes esté configurada para suplantar una cuenta de servicio de IAM.

Integración con Agent Platform

Gemini Enterprise Agent Platform incluye varios productos y servicios diseñados para crear, administrar y operar agentes a gran escala. Si ejecutas cargas de trabajo de agentes en GKE, puedes usar los productos de Agent Platform asignando identidades de agentes a las cargas de trabajo y registrando las cargas de trabajo como agentes en Agent Registry. Para integrar y usar los servicios de Agent Platform con tus agentes de GKE, los operadores de aplicaciones agregan anotaciones y etiquetas a las especificaciones de Kubernetes de las cargas de trabajo de los agentes. Además de verificar que Workload Identity Federation for GKE esté habilitada, no es necesario que realices cambios en la configuración del clúster o del grupo de nodos. Luego, puedes administrar y controlar tus agentes de GKE de la misma manera en que controlarías un agente que se ejecuta en Agent Runtime o Cloud Run.

El registro en Agent Registry también ayuda a prevenir posibles interrupciones cuando mueves proyectos entre organizaciones. Durante la transferencia de un proyecto, el Registro de agentes verifica si algún agente usa una identidad basada en el dominio de confianza a nivel de la organización, que cambiaría después de la transferencia. Si se usa una identidad de agente a nivel de la organización, se bloqueará la transferencia del proyecto. Esta verificación solo se realiza con las implementaciones que registras en Agent Registry. La verificación no se realiza con otros controladores de cargas de trabajo ni con Pods estáticos.

Cómo funciona en GKE

En GKE, Agent Identity usa conceptos como el servidor de metadatos de GKE y los grupos de identidades, de manera similar a Workload Identity Federation for GKE. Para usar Agent Identity, también debes habilitar Workload Identity Federation for GKE en el clúster. Google Cloud crea automáticamente un grupo de identidades del agente a nivel del proyecto o de la organización. El grupo de identidades del agente es un dominio de confianza de SPIFFE y es la raíz de confianza para las identidades y las credenciales del agente. Los desarrolladores de aplicaciones pueden solicitar una identidad de agente para su agente agregando anotaciones y etiquetas a la especificación del Pod. Cuando la carga de trabajo se implementa en un clúster, GKE le asigna las siguientes credenciales:

  • Una identidad de SPIFFE que identifica la carga de trabajo. Todos los Pods de una carga de trabajo administrada, como un Deployment, comparten el ID de SPIFFE de esa carga de trabajo. El ID de SPIFFE identifica al agente en todos los servicios de Google Cloud . Puedes hacer un seguimiento de cualquier acción que realicen los Pods, ya sea como agente o en nombre de un usuario final, con el ID de SPIFFE. El ID de SPIFFE tiene la siguiente sintaxis:

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

    Esta cadena de ID tiene los siguientes atributos:

    • TRUST_DOMAIN: Es el dominio de confianza de SPIFFE, que tiene uno de los siguientes valores, según si el proyecto que contiene el clúster pertenece a una organización o no:
      • Proyectos que pertenecen a una organización: agents.global.org-ORGANIZATION_ID.system.id.goog, donde ORGANIZATION_ID es el ID de la organización.
      • Proyectos que no pertenecen a una organización: agents.global.proj-PROJECT_NUMBER.system.id.goog, donde PROJECT_NUMBER es el número de proyecto del proyecto del clúster.
    • PROJECT_NUMBER: Es el número del proyecto del clúster.
    • CONTROL_PLANE_LOCATION: Es la región o zona en la que se encuentra el plano de control del clúster.
    • CLUSTER_NAME: Es el nombre del clúster en el que se encuentra el Pod.
    • NAMESPACE: Es el nombre del espacio de nombres de Kubernetes en el que se encuentra el Pod.
    • SERVICEACCOUNT_NAME: Es el nombre de la cuenta de servicio de Kubernetes que se asigna al Pod.

  • Un paquete de credenciales de identidad del agente (x509.credential-bundle.private-key.pem) que se activa como un volumen en cada Pod y se puede usar para la autenticación de mTLS en las APIs de Google Cloud . Este archivo incluye las siguientes credenciales:

    • Cadena de certificados X.509 que incluye el ID de SPIFFE para la carga de trabajo del agente como el parámetro Nombre alternativo del sujeto (SAN) y que vence en 24 horas. La cadena de certificados se usa para obtener tokens de acceso vinculados y tokens de identidad para la autenticación en otros servicios.
    • Es una clave privada que el proceso de kubelet crea automáticamente para cada Pod. La clave vincula criptográficamente el certificado X.509 de un Pod al Pod. Esta clave demuestra que el Pod que realizó una solicitud posee el certificado X.509 que se usó para establecer la conexión TLS.

  • Un paquete de confianza de la AC raíz (TRUST_DOMAIN.spiffe-trust-bundle.pem) que se activa como un volumen en cada Pod y se puede usar para configurar la autenticación de mTLS entre los agentes que usan el mismo dominio de confianza. Durante un protocolo de enlace de mTLS, un agente usa el paquete de confianza de la CA raíz para validar la cadena de certificados que presenta un agente par.

Configuración a nivel de la carga de trabajo

Para asignar una identidad de agente y credenciales por Pod a una carga de trabajo, GKE busca las siguientes anotaciones en la especificación del Pod:

  • iam.gke.io/identity: "spiffe://TRUST_DOMAIN/*": GKE usa esta anotación para asignar a los Pods un ID de SPIFFE del dominio de confianza correspondiente.

  • iam.gke.io/inject-podcertificates: "true": GKE usa esta anotación para agregar el paquete de credenciales de identidad del agente y el paquete de confianza del clúster a cada Pod de la carga de trabajo. Si se omite esta anotación, no podrás obtener tokens de acceso vinculados a Pods específicos. Las credenciales insertadas se usan para la autenticación de mTLS desde tus Pods a cualquier API deGoogle Cloud o agentes pares.

Además, Agent Registry usa la siguiente etiqueta y anotación para registrar automáticamente tus agentes de GKE:

  • Etiqueta registry.gke.io/functional-type: "AGENT": Identifica la carga de trabajo como un agente de IA y agrega el agente al registro de agentes. Esta etiqueta solo es compatible con las implementaciones y debe especificarse en el campo metadata.labels del manifiesto de Deployment.
  • Anotación de iam.gke.io/spiffe-identity-type: "agent-identity": Indica que el agente usa la identidad del agente. Esta anotación se especifica en la especificación del Pod. Si se especifica la etiqueta registry.gke.io/functional-type: "AGENT" para una Deployment, esta anotación es obligatoria en la especificación del Pod.

Para integrar tus agentes de GKE en Agent Platform, registra tus cargas de trabajo en Agent Registry además de usar la identidad del agente. Considera aplicar el registro de cargas de trabajo de agentes o automatizar el registro en tu canalización de implementación.

Tokens de acceso para agentes

En GKE, cada Pod que usa la identidad del agente obtiene un paquete de credenciales único que contiene el certificado X.509 y la clave privada del Pod, que no sale del Pod. Para acceder a cualquier API de Google Cloud o servicio externo, un Pod de agente en un clúster de GKE solicita un token de acceso de identidad del agente del servidor de metadatos de GKE que se ejecuta en cada nodo. El Pod usa el token de acceso de identidad del agente para autenticarse como la identidad del agente.

El token de acceso puede estar vinculado o no, de la siguiente manera:

  • Token de acceso vinculado: Está vinculado de forma criptográfica al certificado X.509 del Pod y solo se puede usar en conexiones mTLS que se autenticaron con ese certificado X.509. Cualquier solicitud de token de acceso que incluya el certificado X.509 en la carga útil generará un token vinculado.
  • Token de acceso no vinculado: No está vinculado criptográficamente a un Pod específico y se puede usar en conexiones que no son de mTLS. Los tokens de acceso no vinculados son más vulnerables a los ataques de reproducción de tokens, ya que un Pod diferente puede usar un token filtrado.

Los agentes usan los tokens de acceso vinculados o no vinculados para autenticar sus solicitudes a las APIs deGoogle Cloud . Los administradores de identidades pueden controlar el acceso que tiene un agente especificando el identificador principal del token de acceso de identidad de ese agente en las políticas de IAM, como se describe en Controla el acceso a los recursos de Google Cloud para los agentes.

Si los Pods tienen la anotación iam.gke.io/inject-podcertificates: "true", las bibliotecas cliente de Cloud y las bibliotecas de autenticación de Google usan las credenciales predeterminadas de la aplicación (ADC) para obtener automáticamente un token de acceso de identidad del agente vinculado para los Pods. Es posible que este proceso automático no se produzca en todas las bibliotecas o lenguajes de programación. Para solicitar tokens de acceso no vinculados, los desarrolladores usan uno de los siguientes métodos:

  • Especifica la anotación iam.gke.io/inject-podcertificates: "true" y configura la variable de entorno GOOGLE_API_ENABLE_RUNTIME_BOUND_TOKEN en un valor de false en la especificación del Pod. GKE agrega el paquete de credenciales X.509 al Pod, pero la variable de entorno hace que ADC obtenga tokens de acceso no vinculados.

    Este método permite que los Pods sigan estableciendo conexiones mTLS con otras cargas de trabajo usando los certificados y, al mismo tiempo, usando tokens de acceso no vinculados para acceder a las APIs de Google Cloud .

  • No especifiques la anotación iam.gke.io/inject-podcertificates: "true" en la especificación del Pod. GKE no agrega el paquete de credenciales X.509 al Pod, por lo que el ADC obtiene tokens de acceso no vinculados para los Pods.

  • Envía una solicitud GET HTTP directa al extremo del token del servidor de metadatos de GKE, que devuelve un token de acceso no vinculado.

Flujos de trabajo de autenticación para agentes

A diferencia de las cargas de trabajo que no son de agentes, es posible que los agentes deban autenticarse en los servicios en nombre de un usuario final o como la propia identidad del agente, según la tarea que intente realizar el agente. La identidad del agente admite la autenticación en los siguientes tipos de recursos con varios modelos de autenticación y credenciales:

  • APIs deGoogle Cloud
  • Herramientas y servicios externos
  • Autenticación de agente a agente

Autenticación en las APIs de Google Cloud

Un agente puede usar su propia identidad para autenticarse en las APIs de Google Cloud , como BigQuery o Agent Platform. Para autenticarse, el Pod obtiene un token de acceso de identidad del agente del servidor de metadatos de GKE en el nodo. Este token de acceso se puede vincular de forma opcional al certificado X.509 del Pod, lo que significa que el token de acceso solo se puede usar a través de una conexión mTLS que se autentique con el certificado X.509.

Si tu aplicación usa la versión 2.61.0 o posterior de la biblioteca de autenticación de Python google-auth, las credenciales predeterminadas de la aplicación (ADC) solicitan automáticamente tokens de acceso vinculados para los Pods que tienen el paquete de credenciales de identidad del agente. Si usas las bibliotecas cliente de Cloud para Python, asegúrate de usar una versión que incluya la versión 2.61.0 o posterior de la biblioteca google-auth. Para otros lenguajes de programación o versiones de la biblioteca de Python google-auth anteriores a la 2.61.0, solicita tokens de acceso no vinculados.

Si obtienes un token de acceso vinculado, debes usar el certificado X.509 del Pod para establecer una conexión mTLS con el extremo mTLS de la API de destino. Si obtienes un token de acceso no vinculado, puedes usarlo en solicitudes al extremo sin mTLS de esa API.

Para configurar el código de la aplicación para obtener tokens de acceso vinculados o no vinculados con estos métodos, consulta Autenticación con una identidad de agente en GKE.

Si eres administrador de la plataforma o administrador de seguridad, no necesitas configurar una autenticación adicional para los agentes que se autentican en las APIs deGoogle Cloud . Puedes controlar el acceso a los recursos con políticas de IAM, como se describe en Controla el acceso a los recursos de Google Cloud para los agentes.

Autenticación del agente en servicios externos

A menudo, los agentes necesitan acceder a herramientas y servicios externos con credenciales específicas, como claves de API o tokens de OAuth. Es posible que el agente deba autenticarse como su propia identidad o en nombre de un usuario final. Puedes proporcionarles a los agentes credenciales específicas con el administrador de autenticación de identidad del agente (vista previa). El administrador de autenticación centraliza la adquisición de credenciales y la configuración del flujo de trabajo de autenticación para los agentes que ejecutas en Google Cloud.

En el administrador de autenticación, configuras proveedores de autenticación para controlar flujos de trabajo de autenticación específicos. Cuando un agente en GKE necesita autenticarse con una credencial específica, el Pod usa su token de acceso de identidad del agente para autenticarse en el administrador de autenticación. Luego, el proveedor de autenticación controla los pasos de autenticación adicionales y devuelve la credencial solicitada al Pod. El administrador de autenticación intercambia las credenciales externas por tokens de acceso de corta duración, de modo que los tokens de actualización y los secretos de API de larga duración no se almacenan en el contenedor del agente.

Puedes usar el administrador de autenticación para los siguientes casos de uso, cada uno de los cuales implica una configuración específica en el administrador de autenticación y en el código de la aplicación:

  • Acceder a servicios externos en nombre de un usuario final
  • Acceder a servicios externos con su propia identidad
  • Accede a las APIs con una clave de API.

Puedes supervisar y revocar las credenciales que crea el administrador de autorización. También puedes hacer un seguimiento de las credenciales que usan los agentes específicos, ya que el agente se autentica en el administrador de autorización con su token de acceso de identidad del agente. En las siguientes secciones, se describen los casos de uso del administrador de autenticación y los modelos de autenticación correspondientes. Según el modelo de autenticación que uses, tú y los desarrolladores de tu aplicación deberán realizar cambios específicos en el código del agente y en las aplicaciones del cliente.

Acceso a servicios externos en nombre de un usuario final

Un usuario final puede pedirle a un agente que realice ciertas acciones en su nombre, como escribir mensajes en un canal de Slack o abrir una solicitud de extracción en un repositorio de GitHub. En estos casos, el usuario delega su autoridad en el agente dando su consentimiento explícito para que este actúe en su nombre. Para configurar el consentimiento del usuario y la recuperación de credenciales, usa OAuth de 3 segmentos, que incluye los siguientes pasos:

  1. El proveedor de autenticación redirecciona al usuario para que se autentique en el servicio externo.
  2. El usuario se conecta y aprueba el acceso que necesita el agente.
  3. El servicio externo devuelve una credencial al proveedor de autenticación.

Para configurar OAuth de 3 segmentos para un agente que se ejecuta en GKE, el administrador de la plataforma y el desarrollador de la aplicación deben seguir estos pasos:

  1. El administrador de la plataforma configura el proveedor de autenticación:
    1. Crea un proveedor de autenticación de OAuth de 3 segmentos en el administrador de autenticación.
    2. Configura el proveedor de autenticación para que redireccione al servidor de autorización externo.
    3. Configura el servicio de terceros para que envíe el token de acceso del usuario al proveedor de autenticación.
    4. Autoriza al agente para que acceda al proveedor de autenticación.
  2. El desarrollador de la aplicación modifica la aplicación:
    1. Modifica el código del agente para autenticarte con el proveedor de autenticación.
    2. Modifica el código de la aplicación del cliente para controlar el acceso del usuario, el redireccionamiento y la reanudación de la conversación.

Para obtener más información sobre cómo configurar el proveedor de autenticación y modificar las aplicaciones del agente y del cliente, consulta Autentica con OAuth de 3 segmentos con el administrador de autenticación.

Acceso a servicios externos como identidad del agente

Es posible que un agente necesite acceder a servicios externos, como ServiceNow o Salesforce, con su propia identidad. Por ejemplo, un agente de administración de inventario podría supervisar los datos de ventas y pedir inventario para evitar problemas de stock durante los eventos de ventas pico. En estos casos, se usa OAuth de 2 segmentos, que incluye los siguientes pasos:

  1. El administrador de autorización solicita un token de acceso del servicio externo.
  2. El servicio externo valida la solicitud y devuelve el token de acceso al administrador de autenticación.

Para configurar OAuth de 2 segmentos para un agente que se ejecuta en GKE, haz lo siguiente:

  1. El administrador de la plataforma configura el proveedor de autenticación:
    1. Obtén un ID de cliente de OAuth, secreto del cliente y un extremo de token del servicio externo.
    2. Crea un proveedor de autenticación de OAuth de 2 segmentos en el administrador de autenticación que tenga la información de OAuth del servicio externo.
    3. Autoriza al agente para que acceda al proveedor de autenticación.
  2. El desarrollador de la aplicación modifica el código del agente para autenticarse con el proveedor de autenticación.

Para obtener más información sobre cómo configurar el proveedor de autenticación y modificar el código del agente, consulta Autentica con OAuth de 2 segmentos con el administrador de autenticación.

Acceso a las APIs con una clave de API

Puedes almacenar claves de API en el administrador de autenticación para que los agentes las usen y se autentiquen en APIs externas. Si bien puedes almacenar claves de API en otros almacenes, como Secret Manager, el método del administrador de autorización te permite hacer un seguimiento del acceso de los agentes a las claves de API y administrarlo en una ubicación central. Para almacenar y usar claves de API en el administrador de autorización, haz lo siguiente:

  1. El administrador de la plataforma configura el proveedor de autenticación:
    1. Crea un proveedor de autenticación con clave de API en el administrador de autenticación.
    2. Genera y almacena la clave de API en el proveedor de autenticación.
    3. Autoriza al agente para que acceda al proveedor de autenticación.
  2. Modifica el código del agente para autenticarte con el proveedor de autenticación.

Para obtener más información, consulta Autentica con una clave de API con el administrador de autenticación.

Autenticación de agente a agente

En esta sección, se describe un flujo de trabajo de autenticación avanzado. Ya deberías conocer los siguientes temas:

  • Tokens web JSON (JWT): Los tokens de ID de identidad del agente son JWT firmados.
  • Encabezados de firma y encriptación de objetos JSON (JOSE): Los tokens de ID tienen un encabezado JOSE que describe el algoritmo y la clave de firma del token de ID.
  • Claves web JSON (JWK): Las JWK se usan para firmar tokens de ID. Los JWKS públicos para un grupo de identidades de agente se publican como un conjunto de claves web JSON (JWKS). Usas estas claves públicas para validar los tokens de ID entrantes de otros agentes.

En las arquitecturas multiagente, los agentes suelen colaborar invocando directamente a agentes pares o servicios descendentes. Puedes establecer comunicación directamente entre las cargas de trabajo del agente con un token de identidad de identidad del agente, que es un JWT firmado que puedes obtener del servidor de metadatos de GKE. Para autenticar una conexión entre los servicios del agente, los desarrolladores de aplicaciones hacen lo siguiente:

  1. Obtén un token de ID de identidad del agente del servidor de metadatos de GKE para el agente que realiza la llamada. Este token de ID debe establecer el reclamo aud en el extremo del agente receptor.
  2. Incluye el token de ID en el encabezado de la solicitud Authorization: Bearer de la solicitud HTTP.
  3. En el agente receptor, valida el token de ID entrante con los JWK públicos para el grupo de identidades del agente y los distintos parámetros de encabezado y cuerpo en el token de ID.

Para obtener más información sobre cómo solicitar, usar y validar tokens de ID en el código de la aplicación, consulta Autenticación en otros agentes.

La autenticación de agente a agente no requiere configuración adicional de Google Cloudpor parte de un administrador de la plataforma, ya que este flujo de trabajo omite las verificaciones de autorización de IAM. En cambio, los agentes se comunican directamente entre sí y autorizan acciones según las identidades de los agentes.

Controla el acceso a los recursos de Google Cloud para los agentes

Los administradores de seguridad pueden controlar a qué recursos puede acceder un agente con políticas de IAM que hacen referencia al identificador principal del agente. Para controlar el acceso a los recursos de un agente que se ejecuta en GKE y tiene una identidad de agente, debes incluir uno de los siguientes identificadores de principal en tu política de IAM:

  • Todos los agentes de un dominio de confianza específico:

    principalSet://TRUST_DOMAIN/*

    En este identificador, TRUST_DOMAIN es el dominio de confianza de la jerarquía de recursos, que depende de si el agente se encuentra en un proyecto que pertenece a una organización:

    • Proyectos que pertenecen a una organización: agents.global.org-ORGANIZATION_ID.system.id.goog, donde ORGANIZATION_ID es el ID de la organización.
    • Proyectos que no pertenecen a una organización: agents.global.proj-PROJECT_NUMBER.system.id.goog, donde PROJECT_NUMBER es el número del proyecto del clúster.

  • Un solo agente en un dominio de confianza:

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

    En este identificador, los siguientes parámetros identifican al agente específico:

    • PROJECT_NUMBER: Es el número del proyecto del clúster.
    • CONTROL_PLANE_LOCATION: Es la región o zona del plano de control del clúster.
    • CLUSTER_NAME: Es el nombre del clúster en el que se encuentra el agente.
    • NAMESPACE_NAME: Es el nombre del espacio de nombres de Kubernetes en el que se encuentra el agente.
    • SERVICEACCOUNT_NAME: Es el nombre de la ServiceAccount de Kubernetes que usa la carga de trabajo del agente.

Para obtener más información sobre cómo encontrar identificadores principales para los agentes de GKE y administrar el acceso, consulta Administra el acceso a las APIs de Google Cloud para los agentes.

La identidad del agente admite todos los tipos de políticas de IAM, como las políticas de permisos, las políticas de denegación y las políticas de límite de acceso de la entidad principal (PAB). Para administrar el acceso de un agente en un clúster de GKE que usa la identidad del agente, debes incluir el identificador principal del agente en el tipo de política correspondiente. Para obtener más información sobre cómo configurar cada tipo de política de IAM, consulta los siguientes temas:

Cómo ver y administrar agentes en Google Cloud

Si los desarrolladores de aplicaciones registran sus agentes en Agent Registry, podrás ver los agentes de GKE junto con los demás agentes que ejecutas en Google Cloud. El registro de agentes muestra la identidad SPIFFE del agente, dónde se ejecuta y cualquier información adicional sobre él. Todas las solicitudes a la API autenticadas con Agent Identity generan registros de auditoría de Agent Registry. Según el flujo de trabajo de autenticación que usa el agente, los Registros de auditoría de Cloud proporcionan la siguiente información:

  • Autenticación con la identidad propia del agente: Los registros de auditoría generados incluyen el identificador principal del agente, que puedes usar para encontrar el clúster, el espacio de nombres y la cuenta de servicio del agente.
  • Operaciones delegadas en nombre de los usuarios finales: Los registros de auditoría generados incluyen información sobre el usuario final que autorizó la acción y el ID de SPIFFE del agente que ejecutó la llamada. Esta asociación de identidad en los registros de auditoría te ayuda a validar que el usuario final autorizó acciones específicas.

Además de los Registros de auditoría de Cloud, los desarrolladores de aplicaciones pueden configurar sus cargas de trabajo de agentes para que emitan registros, seguimientos y métricas que se hagan visibles en Google Cloud Observability. Para obtener más información sobre cómo configurar las cargas de trabajo, consulta los siguientes documentos:

Mejora la seguridad de los agentes de GKE

Los administradores de seguridad pueden administrar las medidas de seguridad específicas del agente por separado de las restricciones para otros tipos de cargas de trabajo haciendo referencia a las identidades del agente. Ten en cuenta las siguientes medidas de defensa cuando ejecutes agentes:

Limitaciones

  • Solo puedes registrar automáticamente las implementaciones en Agent Registry. Otros controladores de cargas de trabajo y Pods estáticos no admiten el registro automático.
  • Los tokens de acceso de identidad del agente vinculados solo usan el permiso de OAuth https://www.googleapis.com/auth/cloud-platform. No puedes especificar un alcance diferente para los tokens de acceso vinculados.
  • La recuperación automática de tokens de acceso o de ID vinculados solo se admite en las aplicaciones de Python que usan la versión 2.61.0 o posterior de la biblioteca google-auth. Si usas las bibliotecas cliente de Cloud para Python, debes usar una versión que incluya la versión 2.61.0 o posterior de la biblioteca google-auth.
  • Es posible que algunas bibliotecas cliente de Cloud no enruten automáticamente tus solicitudes a los extremos de mTLS.
  • Para la autenticación de agente a agente, solo puedes usar tokens de ID vinculados para autenticar agentes que se encuentran en el mismo dominio de confianza de identidad del agente.

¿Qué sigue?