Sobre a identidade do agente para o GKE

As cargas de trabalho de agentes geralmente exigem medidas de defesa, controle de acesso e fluxos de trabalho de autenticação diferentes de outros tipos de cargas de trabalho. É possível usar a identidade do agente para dar a cada agente uma identidade atestada, de curta duração e por pod. Essa identidade ajuda a identificar cargas de trabalho do agente e a rastrear e gerenciar o que essas cargas de trabalho fazem no Google Cloud. Este documento descreve como a identidade do agente funciona no Google Kubernetes Engine (GKE), incluindo como integrar a outros produtos doGoogle Cloud , os tipos de autenticação que seus agentes podem usar e como governar suas cargas de trabalho usando essas identidades.

Este documento é destinado a administradores de plataforma e engenheiros de segurança que querem melhorar a segurança dos agentes executados em clusters do GKE ao integrar os agentes com produtos e serviços do Google Cloud .

Você já precisa conhecer os seguintes tópicos:

O que é a identidade do agente?

OGoogle Cloud oferece vários tipos de identidade para suas cargas de trabalho, cada um destinado a um conjunto específico de casos de uso e tipos de carga de trabalho. A identidade do agente é um tipo de identidade projetado para cargas de trabalho de agentes de IA. Um agente que usa a identidade do agente recebe uma identidade exclusiva baseada no padrão SPIFFE. Essa identidade está vinculada ao ciclo de vida do agente, identifica a carga de trabalho como um agente e é reconhecida pelos vários serviços da Gemini Enterprise Agent Platform, como o Agent Registry e o Gateway de Agente. É possível rastrear e gerenciar uma carga de trabalho que tem uma identidade de agente em todos os serviços acessados por ela, independente de onde ela é executada. Uma carga de trabalho que usa a identidade do agente pode autenticar servidores MCP, recursos dentro e fora de Google Cloud, outros agentes e endpoints usando a própria identidade ou em nome de um usuário final. Para mais informações sobre a identidade do agente, consulte a visão geral da identidade do agente.

É possível usar a identidade do agente para melhorar a segurança e a governança dos agentes de IA implantados em clusters do GKE e ativar fluxos de trabalho específicos para seus agentes, como:

  • Integre agentes no GKE com produtos como o Agent Registry e o Gateway de Agente.
  • Gerenciar papéis para cargas de trabalho de agentes em projetos, pastas ou organizações nas políticas do Identity and Access Management (IAM).
  • Reduza o impacto de agentes comprometidos em nós e outros pods no cluster.
  • Configure vários fluxos de trabalho de autenticação, como agentes agindo em nome de usuários finais, usando o gerenciador de autenticação de identidade do agente.

Comparação com a Federação de Identidade da Carga de Trabalho para GKE

A Identidade do Agente e a Federação de Identidade da Carga de Trabalho para GKE oferecem maneiras de atribuir identidades às cargas de trabalho. A identidade do agente foi projetada para o modelo de ameaça e requisitos específicos aplicáveis a agentes de IA, o que resulta em várias diferenças funcionais. A tabela a seguir oferece uma comparação geral dessas diferenças:

Identidade do agente Federação de Identidade da Carga de Trabalho para GKE
Os tokens de acesso à identidade do agente podem ser vinculados criptograficamente a certificados X.509 por pod. Um token de acesso vinculado exige uma conexão mTLS e não funciona quando usado fora do pod original. Tokens de acesso federados não são vinculados criptograficamente a identidades de pod, funcionam em conexões não mTLS e podem ser usados fora do pod original.
Integra-se ao gerenciador de autenticação de identidade do agente para oferecer suporte a fluxos de trabalho do OAuth e usar credenciais de terceiros sem gerenciamento manual de credenciais. Requer implementação manual de fluxos de trabalho do OAuth e gerenciamento de credenciais de terceiros ao autenticar ferramentas e serviços externos.
Funciona bem para cargas de trabalho autônomas, como agentes de IA. Funciona bem para microsserviços determinísticos, como servidores da Web, APIs e jobs em lote.
Requer o GKE versão 1.37.0-gke.3503000 ou posterior. Disponível em todas as versões do GKE.
Os tokens de acesso de identidade do agente vinculados sempre usam o escopo de acesso https://www.googleapis.com/auth/cloud-platform. Não há suporte para escopos personalizados. Os tokens de acesso federados oferecem suporte a escopos de acesso personalizados.
Os aplicativos podem receber tokens de ID de identidade do agente para autenticar diretamente outras cargas de trabalho ou serviços downstream. Os aplicativos não podem receber tokens de ID, a menos que a conta de serviço do Kubernetes esteja configurada para representar uma conta de serviço do IAM.

Integração com a Agent Platform

A Gemini Enterprise Agent Platform inclui vários produtos e serviços projetados para criar, governar e operar agentes em grande escala. Se você executar cargas de trabalho de agente no GKE, poderá usar os produtos da plataforma de agentes atribuindo identidades de agente às cargas de trabalho e registrando-as como agentes no Agent Registry. Para integrar e usar os serviços da Agent Platform com seus agentes do GKE, os operadores de aplicativos adicionam anotações e rótulos às especificações do Kubernetes das cargas de trabalho do agente. Além de verificar se a federação de identidade da carga de trabalho para GKE está ativada, não é necessário fazer mudanças na configuração do cluster ou do pool de nós. Em seguida, é possível gerenciar e controlar seus agentes do GKE da mesma forma que um agente executado no Agent Runtime ou no Cloud Run.

O registro no Agent Registry também ajuda a evitar possíveis interrupções ao mover projetos entre organizações. Durante a movimentação de um projeto, o Agent Registry verifica se algum agente usa uma identidade baseada no domínio de confiança no nível da organização, que mudaria após a movimentação. Se uma identidade de agente no nível da organização estiver em uso, a movimentação do projeto será bloqueada. Essa verificação acontece apenas com implantações registradas no Agent Registry. A verificação não acontece com outros controladores de carga de trabalho ou pods estáticos.

Como funciona no GKE

No GKE, a Identidade do Agente usa conceitos como o servidor de metadados do GKE e pools de identidade, de maneira semelhante à Federação de Identidade da Carga de Trabalho para GKE. Para usar a identidade do agente, também é necessário ativar a Federação de Identidade da Carga de Trabalho para GKE no cluster.O Google Cloud cria automaticamente um pool de identidade do agente no nível do projeto ou da organização. O pool de identidades do agente é um domínio de confiança SPIFFE e é a raiz de confiança para identidades e credenciais do agente. Os desenvolvedores de aplicativos podem solicitar uma identidade de agente para o agente deles adicionando anotações e rótulos à especificação do pod. Quando a carga de trabalho é implantada em um cluster, o GKE atribui as seguintes credenciais a ela:

  • Uma identidade SPIFFE que identifica a carga de trabalho. Todos os pods em uma carga de trabalho gerenciada, como uma implantação, compartilham o ID do SPIFFE dessa carga de trabalho. O ID do SPIFFE identifica o agente em todos os serviços do Google Cloud . Você pode rastrear todas as ações realizadas pelos pods, seja como o agente ou em nome de um usuário final, usando o ID do SPIFFE. O ID do SPIFFE tem a seguinte sintaxe:

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

    Essa string de ID tem os seguintes atributos:

    • TRUST_DOMAIN: o domínio de confiança SPIFFE, que tem um dos seguintes valores, dependendo se o projeto que contém o cluster está em uma organização:
      • Projetos em uma organização: agents.global.org-ORGANIZATION_ID.system.id.goog, em que ORGANIZATION_ID é o ID da organização.
      • Projetos que não estão em uma organização: agents.global.proj-PROJECT_NUMBER.system.id.goog, em que PROJECT_NUMBER é o número do projeto do cluster.
    • PROJECT_NUMBER: o número do projeto do cluster.
    • CONTROL_PLANE_LOCATION: a região ou zona em que o plano de controle do cluster está.
    • CLUSTER_NAME: o nome do cluster em que o pod está.
    • NAMESPACE: o nome do namespace do Kubernetes em que o pod está.
    • SERVICEACCOUNT_NAME: o nome da conta de serviço do Kubernetes atribuída ao pod.

  • Um pacote de credenciais de identidade do agente (x509.credential-bundle.private-key.pem) montado como um volume em cada pod e que pode ser usado para autenticação mTLS em APIs Google Cloud . Esse arquivo inclui as seguintes credenciais:

    • Uma cadeia de certificados X.509 que inclui o ID do SPIFFE para a carga de trabalho do agente como o parâmetro de nome alternativo do assunto (SAN) e expira em 24 horas. A cadeia de certificados é usada para receber tokens de acesso vinculados e tokens de identidade para autenticação em outros serviços.
    • Uma chave privada que o processo kubelet cria automaticamente para cada Pod. A chave vincula criptograficamente o certificado X.509 de um pod ao pod. Essa chave prova que o pod que fez uma solicitação é proprietário do certificado X.509 usado para estabelecer a conexão TLS.

  • Um pacote de confiança de CA raiz (TRUST_DOMAIN.spiffe-trust-bundle.pem) montado como um volume em cada pod e que pode ser usado para configurar a autenticação mTLS entre agentes que usam o mesmo domínio de confiança. Durante um handshake mTLS, um agente usa o pacote de confiança da CA raiz para validar a cadeia de certificados apresentada por um agente de mesmo nível.

Configuração no nível da carga de trabalho

Para atribuir uma identidade de agente e credenciais por pod a uma carga de trabalho, o GKE procura as seguintes anotações na especificação do pod:

  • iam.gke.io/identity: "spiffe://TRUST_DOMAIN/*": o GKE usa essa anotação para atribuir aos pods um ID do SPIFFE do domínio de confiança correspondente.

  • iam.gke.io/inject-podcertificates: "true": o GKE usa essa anotação para adicionar o pacote de credenciais de identidade do agente e o pacote de confiança do cluster a cada pod na carga de trabalho. Se essa anotação for omitida, não será possível receber tokens de acesso vinculados a pods específicos. As credenciais injetadas são usadas para autenticação mTLS dos seus pods para qualquer APIGoogle Cloud ou agentes de peer.

Além disso, o Agent Registry usa o seguinte rótulo e anotação para registrar automaticamente seus agentes do GKE:

  • Rótulo registry.gke.io/functional-type: "AGENT": identifica a carga de trabalho como um agente de IA e adiciona o agente ao Agent Registry. Esse rótulo é compatível apenas com implantações e precisa ser especificado no campo metadata.labels do manifesto de implantação.
  • Anotação iam.gke.io/spiffe-identity-type: "agent-identity": indica que o agente usa a identidade do agente. Essa anotação é especificada na especificação do pod. Se o rótulo registry.gke.io/functional-type: "AGENT" for especificado para uma implantação, essa anotação será necessária na especificação do pod.

Para integrar seus agentes do GKE à Agent Platform, registre suas cargas de trabalho no Agent Registry além de usar a identidade do agente. Considere forçar o registro de cargas de trabalho de agente ou automatizar o registro no seu pipeline de implantação.

Tokens de acesso para agentes

No GKE, cada pod que usa a identidade do agente recebe um pacote de credenciais exclusivo que contém o certificado X.509 e a chave privada do pod, que não sai do pod. Para acessar qualquer API Google Cloud ou serviço externo, um pod de agente em um cluster do GKE solicita um token de acesso de identidade do agente do servidor de metadados do GKE executado em cada nó. O pod usa o token de acesso da identidade do agente para fazer a autenticação como a identidade do agente.

O token de acesso pode ser vinculado ou não vinculado, da seguinte forma:

  • Token de acesso vinculado: vinculado criptograficamente ao certificado X.509 do pod e pode ser usado apenas em conexões mTLS autenticadas com esse certificado X.509. Qualquer solicitação de token de acesso que inclua o certificado X.509 no payload resulta em um token vinculado.
  • Token de acesso não vinculado: não está criptograficamente vinculado a um pod específico e pode ser usado em conexões não mTLS. Tokens de acesso não vinculados são mais vulneráveis a ataques de repetição de token, porque um token vazado pode ser usado por um pod diferente.

Os agentes usam os tokens de acesso vinculados ou não vinculados para autenticar as solicitações às APIs Google Cloud . Os administradores de identidade podem controlar o acesso de um agente especificando o identificador principal do token de acesso à identidade do agente em políticas do IAM, conforme descrito em Controlar o acesso aos recursos do Google Cloud para agentes.

Se os pods tiverem a anotação iam.gke.io/inject-podcertificates: "true", as bibliotecas de cliente do Cloud e de autenticação do Google usarão o Application Default Credentials (ADC) para receber automaticamente um token de acesso à identidade do agente vinculado para pods. Esse processo automático pode não ocorrer em todas as bibliotecas ou linguagens de programação. Para solicitar tokens de acesso não vinculados, os desenvolvedores usam um dos seguintes métodos:

  • Especifique a anotação iam.gke.io/inject-podcertificates: "true" e defina a variável de ambiente GOOGLE_API_ENABLE_RUNTIME_BOUND_TOKEN com um valor de false na especificação do pod. O GKE adiciona o pacote de credenciais X.509 ao pod, mas a variável de ambiente faz com que o ADC receba tokens de acesso não vinculados.

    Esse método permite que os pods continuem estabelecendo conexões mTLS com outras cargas de trabalho usando os certificados e também tokens de acesso não vinculados para acessar APIs Google Cloud .

  • Não especifique a anotação iam.gke.io/inject-podcertificates: "true" na especificação do pod. O GKE não adiciona o pacote de credenciais X.509 ao pod. Assim, o ADC recebe tokens de acesso não vinculados para os pods.

  • Envie uma solicitação HTTP GET direta ao endpoint de token do servidor de metadados do GKE, que retorna um token de acesso não vinculado.

Fluxos de trabalho de autenticação para agentes

Ao contrário das cargas de trabalho sem agente, os agentes podem precisar se autenticar em serviços em nome de um usuário final ou como a própria identidade do agente, dependendo da tarefa que o agente está tentando realizar. A identidade do agente oferece suporte à autenticação para os seguintes tipos de recursos usando várias credenciais e modelos de autenticação:

  • APIs deGoogle Cloud
  • Ferramentas e serviços externos
  • Autenticação de agente para agente

Autenticação em APIs Google Cloud

Um agente pode usar a própria identidade para se autenticar nas APIs Google Cloud , como o BigQuery ou a Agent Platform. Para autenticar, o pod recebe um token de acesso de identidade do agente do servidor de metadados do GKE no nó. Esse token de acesso pode ser vinculado ao certificado X.509 do pod, o que significa que ele só pode ser usado em uma conexão mTLS autenticada com o certificado X.509.

Se o aplicativo usa a versão 2.61.0 ou mais recente da biblioteca de autenticação do Python google-auth, o Application Default Credentials (ADC) solicita automaticamente tokens de acesso vinculados para pods que têm o pacote de credenciais de identidade do agente. Se você usa as bibliotecas de cliente do Cloud para Python, verifique se está usando uma versão que inclui a versão 2.61.0 ou mais recente da biblioteca google-auth. Para outras linguagens de programação ou versões da biblioteca Python google-auth anteriores a 2.61.0, solicite tokens de acesso não vinculados.

Se você receber um token de acesso vinculado, use o certificado X.509 do pod para estabelecer uma conexão mTLS com o endpoint mTLS da API de destino. Se você receber um token de acesso não vinculado, poderá usá-lo em solicitações para o endpoint não mTLS dessa API.

Para configurar o código do aplicativo e receber tokens de acesso vinculados ou não vinculados usando esses métodos, consulte Autenticar usando uma identidade de agente no GKE.

Se você for um administrador da plataforma ou de segurança, não precisará configurar autenticação adicional para agentes que se autenticam nas APIs doGoogle Cloud . É possível controlar o acesso aos recursos usando políticas do IAM, conforme descrito em Controlar o acesso aos recursos do Google Cloud para agentes.

Autenticação do agente em serviços externos

Os agentes geralmente precisam acessar ferramentas e serviços externos usando credenciais específicas, como chaves de API ou tokens OAuth. O agente pode precisar se autenticar como identidade própria ou em nome de um usuário final. É possível fornecer aos agentes credenciais específicas usando o gerenciador de autenticação de identidade do agente (prévia). O gerenciador de autenticação centraliza a aquisição de credenciais e a configuração do fluxo de trabalho de autenticação para agentes executados no Google Cloud.

No gerenciador de autenticação, você configura provedores de autenticação para processar fluxos de trabalho de autenticação específicos. Quando um agente no GKE precisa se autenticar usando uma credencial específica, o pod usa o token de acesso da identidade do agente para se autenticar no gerenciador de autenticação. Em seguida, o provedor de autenticação processa etapas de autenticação adicionais e retorna a credencial solicitada ao pod. O gerenciador de autenticação troca as credenciais externas por tokens de acesso de curta duração para que tokens de atualização de longa duração e chaves secretas da API não sejam armazenados no contêiner do agente.

Você pode usar o gerenciador de autenticação nos seguintes casos de uso, cada um deles envolvendo configuração específica no gerenciador de autenticação e no código do aplicativo:

  • Acessar serviços externos em nome de um usuário final.
  • Acessar serviços externos como a própria identidade.
  • Acessar APIs usando uma chave de API.

É possível monitorar e revogar as credenciais criadas pelo gerenciador de autenticação. Também é possível rastrear quais credenciais agentes específicos usam, porque o agente se autentica no gerenciador de autenticação usando o token de acesso à identidade do agente. As seções a seguir descrevem os casos de uso do gerenciador de autenticação e os modelos de autenticação correspondentes. Dependendo do modelo de autenticação usado, você e os desenvolvedores de aplicativos precisam fazer mudanças específicas no código do agente e nos aplicativos do lado do cliente.

Acesso a serviços externos em nome de um usuário final

Um usuário final pode pedir que um agente realize determinadas ações em nome dele, como escrever mensagens em um canal do Slack ou abrir uma solicitação de envio em um repositório do GitHub. Nesses cenários, o usuário delega a autoridade ao agente ao consentir explicitamente que ele aja em nome do usuário. Para configurar o consentimento do usuário e a recuperação de credenciais, use o OAuth de três etapas, que envolve as seguintes etapas:

  1. O provedor de autenticação redireciona o usuário para autenticação no serviço externo.
  2. O usuário faz login e aprova o acesso necessário para o agente.
  3. O serviço externo retorna uma credencial ao provedor de autenticação.

Para configurar o OAuth de três vias para um agente que é executado no GKE, o administrador da plataforma e o desenvolvedor de aplicativos seguem estas etapas:

  1. O administrador da plataforma configura o provedor de autenticação:
    1. Crie um provedor de autenticação OAuth de três etapas no gerenciador de autenticação.
    2. Configure o provedor de autenticação para redirecionar ao servidor de autorização de terceiros.
    3. Configure o serviço de terceiros para enviar o token de acesso do usuário ao provedor de autenticação.
    4. Autorize o agente a acessar o provedor de autenticação.
  2. O desenvolvedor de aplicativos modifica o aplicativo:
    1. Modifique o código do agente para autenticar usando o provedor de autenticação.
    2. Modifique o código do aplicativo do lado do cliente para processar o login do usuário, redirecionamento e retomada da conversa.

Para mais informações sobre como configurar o provedor de autenticação e modificar seus aplicativos do agente e do lado do cliente, consulte Autenticar usando o OAuth de três etapas com o gerenciador de autenticação.

Acesso a serviços externos como a identidade do agente

Um agente pode precisar acessar serviços externos, como ServiceNow ou Salesforce, usando a própria identidade. Por exemplo, um agente de gerenciamento de inventário pode monitorar dados de vendas e fazer pedidos para evitar problemas de estoque durante eventos de pico de vendas. Nesses cenários, você usa o OAuth de duas etapas, que envolve as seguintes etapas:

  1. O gerenciador de autenticação solicita um token de acesso do serviço externo.
  2. O serviço externo valida a solicitação e retorna o token de acesso ao gerenciador de autenticação.

Para configurar o OAuth de duas etapas para um agente que é executado no GKE, faça o seguinte:

  1. O administrador da plataforma configura o provedor de autenticação:
    1. Receba um ID do cliente OAuth, uma chave secreta do cliente e um endpoint de token do serviço externo.
    2. Crie um provedor de autenticação OAuth de duas etapas no gerenciador de autenticação que tenha as informações do OAuth do serviço externo.
    3. Autorize o agente a acessar o provedor de autenticação.
  2. O desenvolvedor de aplicativos modifica o código do agente para autenticar usando o provedor de autenticação.

Para mais informações sobre como configurar o provedor de autenticação e modificar o código do agente, consulte Autenticar usando o OAuth de duas etapas com o gerenciador de autenticação.

Acesso às APIs usando uma chave de API

É possível armazenar chaves de API no gerenciador de autenticação para que os agentes usem na autenticação em APIs externas. Embora seja possível armazenar chaves de API em outros cofres, como o Secret Manager, o método do gerenciador de autenticação permite rastrear e gerenciar o acesso do agente às chaves de API em um local central. Para armazenar e usar chaves de API no auth manager, faça o seguinte:

  1. O administrador da plataforma configura o provedor de autenticação:
    1. Crie um provedor de autenticação de chave de API no gerenciador de autenticação.
    2. Gere e armazene a chave de API no provedor de autenticação.
    3. Autorize o agente a acessar o provedor de autenticação.
  2. Modifique o código do agente para autenticar usando o provedor de autenticação.

Para mais informações, consulte Autenticar usando chave de API com o gerenciador de autenticação.

Autenticação de agente para agente

Esta seção descreve um fluxo de trabalho de autenticação avançada. Você já precisa conhecer os seguintes tópicos:

Em arquiteturas multiagentes, os agentes colaboram com frequência invocando diretamente agentes semelhantes ou serviços downstream. É possível estabelecer comunicação direta entre cargas de trabalho do agente usando um token de identidade do agente, que é um JWT assinado que você pode receber do servidor de metadados do GKE. Para autenticar uma conexão entre serviços de agente, os desenvolvedores de aplicativos fazem o seguinte:

  1. Receba um token de ID de identidade do agente do servidor de metadados do GKE para o agente de chamada. Esse token de ID precisa definir a declaração aud como o endpoint do agente receptor.
  2. Inclua o token de ID no cabeçalho da solicitação Authorization: Bearer da solicitação HTTP.
  3. No agente de recebimento, valide o token de ID recebido usando os JWKs públicos para o pool de identidades do agente e os vários parâmetros de cabeçalho e corpo no token de ID.

Para mais informações sobre como solicitar, usar e validar tokens de ID no código do aplicativo, consulte Autenticar em outros agentes.

A autenticação de agente para agente não exige configuração adicional de Google Cloud de um administrador da plataforma, porque esse fluxo de trabalho ignora as verificações de autorização do IAM. Em vez disso, os agentes se comunicam diretamente entre si e autorizam ações com base nas identidades dos agentes.

Controlar o acesso a recursos do Google Cloud para agentes

Os administradores de segurança podem controlar quais recursos um agente pode acessar usando políticas do IAM que referenciam o identificador principal do agente. Para controlar o acesso aos recursos de um agente executado no GKE e que tem uma identidade de agente, inclua um dos seguintes identificadores principais na política do IAM:

  • Todos os agentes em um domínio de confiança específico:

    principalSet://TRUST_DOMAIN/*

    Nesse identificador, TRUST_DOMAIN é o domínio de confiança da hierarquia de recursos, que depende de o agente estar em um projeto dentro de uma organização:

    • Projetos em uma organização: agents.global.org-ORGANIZATION_ID.system.id.goog, em que ORGANIZATION_ID é o ID da organização.
    • Projetos que não estão em uma organização: agents.global.proj-PROJECT_NUMBER.system.id.goog, em que PROJECT_NUMBER é o número do projeto do projeto do cluster.

  • Um único agente em um domínio de confiança:

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

    Nesse identificador, os seguintes parâmetros identificam o agente específico:

    • PROJECT_NUMBER: o número do projeto do cluster.
    • CONTROL_PLANE_LOCATION: a região ou zona do plano de controle do cluster.
    • CLUSTER_NAME: o nome do cluster em que o agente está.
    • NAMESPACE_NAME: o nome do namespace do Kubernetes em que o agente está.
    • SERVICEACCOUNT_NAME: o nome da conta de serviço do Kubernetes usada pela carga de trabalho do agente.

Para mais informações sobre como encontrar identificadores principais para agentes do GKE e gerenciar o acesso, consulte Gerenciar o acesso às APIs do Google Cloud para agentes.

A identidade do agente é compatível com todos os tipos de políticas do IAM, como políticas de permissão, de negação e de limite de acesso de principal (PAB, na sigla em inglês). Para gerenciar o acesso de um agente em um cluster do GKE que usa a identidade do agente, inclua o identificador principal do agente no tipo de política correspondente. Para mais informações sobre como configurar cada tipo de política do IAM, consulte os seguintes tópicos:

Ver e gerenciar agentes no Google Cloud

Se os desenvolvedores de aplicativos registrarem os agentes no Agent Registry, será possível ver os agentes do GKE junto com os outros agentes que você executa em Google Cloud. O Agent Registry mostra a identidade SPIFFE do agente, onde ele é executado e outras informações sobre ele. Todas as solicitações de API autenticadas usando a identidade do agente geram registros de auditoria do Agent Registry. Dependendo do fluxo de trabalho de autenticação usado pelo agente, os Registros de auditoria do Cloud fornecem as seguintes informações:

  • Autenticação usando a própria identidade do agente: os registros de auditoria gerados incluem o identificador principal do agente, que pode ser usado para encontrar o cluster, o namespace e a ServiceAccount do agente.
  • Operações delegadas em nome dos usuários finais: os registros de auditoria gerados incluem informações sobre o usuário final que autorizou a ação e o ID SPIFFE do agente que executou a chamada. Essa associação de identidade nos registros de auditoria ajuda a validar se o usuário final autorizou ações específicas.

Além dos registros de auditoria do Cloud, os desenvolvedores de aplicativos podem configurar as cargas de trabalho do agente para emitir rastreamentos, registros e métricas que ficam visíveis no Google Cloud Observability. Para mais informações sobre como configurar as cargas de trabalho, consulte os seguintes documentos:

Melhorar a segurança dos agentes do GKE

Os administradores de segurança podem gerenciar medidas de segurança específicas do agente separadamente das restrições para outros tipos de cargas de trabalho referenciando as identidades do agente. Considere as seguintes medidas de defesa ao executar agentes:

Limitações

  • É possível registrar automaticamente apenas implantações no Agent Registry. Outros controladores de carga de trabalho e pods estáticos não oferecem suporte ao registro automático.
  • Os tokens de acesso de identidade do agente vinculados usam apenas o escopo OAuth https://www.googleapis.com/auth/cloud-platform. Não é possível especificar um escopo diferente para os tokens de acesso vinculados.
  • A recuperação automática de tokens de acesso ou tokens de ID vinculados é compatível apenas em aplicativos Python que usam a versão 2.61.0 ou mais recente da biblioteca google-auth. Se você usa as bibliotecas de cliente do Cloud para Python, use uma versão que inclua a versão 2.61.0 ou mais recente da biblioteca google-auth.
  • Algumas bibliotecas de cliente do Cloud podem não encaminhar automaticamente suas solicitações para endpoints mTLS.
  • Para autenticação de agente para agente, use tokens de ID vinculados apenas para autenticar entre agentes que estão no mesmo domínio de confiança de identidade do agente.

A seguir