Práticas recomendadas para usar a federação de identidade da carga de trabalho

A federação de identidade da carga de trabalho permite que os aplicativos em execução fora do Google Cloud personifiquem uma conta de serviço usando credenciais de um provedor de identidade externo.

O uso da federação de identidade da carga de trabalho pode ajudar a melhorar a segurança, permitindo que os aplicativos usem os mecanismos de autenticação fornecidos pelo ambiente externo e possam substituir as chaves da conta de serviço.

Para usar a federação de identidade da carga de trabalho com segurança, é necessário configurá-la de maneira que protege você das seguintes ameaças:

Spoofing:um usuário de má-fé pode tentar falsificar a identidade de outro usuário para receber acesso não autorizado aos recursos do Google Cloud.
Encaminhamento de privilégios: um usuário de má-fé pode aproveitar a federação de identidade da carga de trabalho para ter acesso a recursos aos quais ele não teria acesso de outra forma.
Não repúdio: um usuário de má-fé pode ocultar a identidade e as ações usando credenciais externas, o que dificulta o rastreamento de ações para elas.

Neste guia, apresentamos as práticas recomendadas para decidir quando usar a federação de identidade da carga de trabalho e como configurá-la de maneira que ajude a minimizar riscos.

Quando usar a federação de identidade da carga de trabalho

Práticas recomendadas:

Use a federação de identidade da carga de trabalho para aplicativos que têm acesso a credenciais de ambiente.
Usar uma troca de token extra para usar credenciais de ambiente que não são compatíveis com a federação de identidade da carga de trabalho.
Usar a federação de identidade da carga de trabalho para reduzir o número de credenciais que exigem rotação.

Usar a federação de identidade de carga de trabalho para aplicativos que têm acesso a credenciais de ambiente

Aplicativos executados em provedores de nuvem que não sejam o Google Cloud geralmente têm acesso a credenciais de ambiente. Essas são as credenciais que o aplicativo pode conseguir sem precisar executar nenhuma autenticação adicional. Por exemplo:

Na AWS, os aplicativos implantados no EC2 podem usar perfis de instâncias para assumir um papel e receber credenciais temporárias.
No Azure, os aplicativos usam as identidades gerenciadas para receber tokens de acesso.
Em ações do GitHub, os fluxos de trabalho podem receber tokens de ID que reflitam a identidade do job de implantação.

Se as credenciais de ambiente forem tokens OpenID Connect (OIDC), declarações SAML ou credenciais da AWS, será possível configurar a federação de identidade da carga de trabalho para permitir que os aplicativos troquem essas credenciais por acesso de curta duração ao Google. . Se as credenciais de ambiente usarem um formato diferente, primeiro será possível trocá-las por um token OIDC ou uma declaração SAML e usá-las para a federação de identidade da carga de trabalho.

Use a federação de identidade da carga de trabalho sempre que um aplicativo precisar acessar o Google Cloud e tiver acesso a credenciais de ambiente.

Use uma troca de token extra para usar credenciais de ambiente que não são compatíveis com a federação de identidade da carga de trabalho

Em alguns casos, um aplicativo pode ter acesso a credenciais de ambiente, mas os tipos de credenciais não são compatíveis com a federação de identidade da carga de trabalho. Nesses casos, verifique se outra troca de token permite converter a credencial do ambiente em um tipo de credencial que possa ser usado para a federação de identidade da carga de trabalho.

Por exemplo, se o aplicativo for executado em um ambiente do Active Directory, ele poderá ter acesso a credenciais do Kerberos. Se você tiver um provedor de identidade como o Active Directory Federation Services (AD FS) no ambiente que seja compatível com a Autenticação integrada do Windows, use estas credenciais do Kerberos para autenticar: o provedor de identidade e conseguir um token de acesso de OAuth que usa o formato JWT. Usando esse token de acesso e a federação de identidade da carga de trabalho, você pode permitir que o aplicativo realize uma segunda troca de tokens para receber credenciais de curta duração do Google.

O encadeamento de trocas de token aumenta a complexidade e pode gerar mais dependências, mas isso evita a necessidade de gerenciar e proteger chaves de contas de serviço.

Usar a federação de identidade de carga de trabalho para reduzir o número de credenciais que exigem rotação

Os aplicativos que se integram a um provedor de identidade OpenID ou SAML geralmente usam uma chave secreta do cliente (ou uma forma de secret diferente) para se autenticar no provedor de identidade. Normalmente, esse secret é armazenado como parte da configuração do aplicativo. Para permitir que esse aplicativo acesse o Google Cloud, você precisa decidir o seguinte:

Criar uma chave da conta de serviço e armazená-la junto com o outro secret.
Usar os tokens emitidos pelo provedor de identidade atual e trocá-los por credenciais do Google usando a federação de identidade da carga de trabalho.

A primeira opção requer dois secrets, mas a segunda exige apenas um. Reduzir o número de secrets pode ajudar a simplificar a rotação de secrets, o que, por sua vez, ajuda a melhorar a segurança.

Como se proteger contra ameaças de spoofing

Um pool de identidades de carga de trabalho não contém identidades ou contas de usuário, o que o torna diferente de um diretório de usuários, como o Cloud Identity. Em vez disso, um pool de identidades de carga de trabalho representa uma visualização que exibe identidades de provedores de identidade externos para que possam ser usadas como principais do IAM.

Dependendo de como você configura o pool de identidades de carga de trabalho e os provedores, a mesma identidade externa pode ser representada como vários principais diferentes do IAM ou várias identidades externas podem ser mapeadas para o mesmo principal do IAM. Essas ambiguidades podem permitir que pessoas mal-intencionadas iniciem ataques de spoofing.

Na seção a seguir, descrevemos as práticas recomendadas para evitar mapeamentos ambíguos e reduzir o risco de ameaças de spoofing.

Práticas recomendadas:

Use condições de atributos ao federar com o GitHub ou outros provedores de identidade multilocatários.
Usar um projeto dedicado para gerenciar provedores e pools de identidades de carga de trabalho
Usar restrições da política da organização para desativar a criação de provedores de pools de Identidades de cargas de trabalho em outros projetos.
Usar um único provedor por pool de identidade da carga de trabalho para evitar conflitos de assunto.
Evite federar com o mesmo provedor de identidade duas vezes.
Proteger o endpoint de metadados OIDC do seu provedor de identidade.
Usar o URL do provedor de pools de identidades de carga de trabalho como público-alvo.
Usar atributos imutáveis nos mapeamentos de atributos.
Use atributos não reutilizáveis em mapeamentos de atributos.
Não permita que os mapeamentos de atributos sejam modificados.
Não dependa de atributos não estáveis ou autoritativos.

Usar condições de atributos ao federar com o GitHub ou outros provedores de identidade multilocatários

A federação de identidade da carga de trabalho não mantém um diretório de contas de usuário. Em vez disso, ela implementa identidades baseadas em declarações. Como resultado, quando dois tokens são emitidos pelo mesmo provedor de identidade (IdP) e as declarações deles são mapeadas para o mesmo valor google.subject, os dois tokens identificam o mesmo usuário. Para descobrir qual IdP emitiu um token, a federação de identidade da carga de trabalho inspeciona e verifica o URL do emissor do token.

Alguns provedores, como o GitHub e o Terraform Cloud, usam um único URL de emissor em todos os locatários. Para esses provedores, o URL do emissor identifica todo o GitHub ou o Terraform Cloud, e não uma organização específica do GitHub ou do Terraform Cloud.

Quando você usa esses provedores de identidade, não é suficiente permitir que a federação de identidade da carga de trabalho verifique o URL do emissor de um token para garantir que ele venha de uma fonte confiável e que as declarações sejam confiáveis. Recomendamos que você configure uma condição do atributo de federação de identidade da carga de trabalho para verificar se o token foi originado de um locatário confiável ou, no caso do GitHub ou do Terraform Cloud, de uma organização confiável.

Para saber mais, consulte Configurar uma condição de atributo.

Usar um projeto dedicado para gerenciar provedores e pools de identidades de carga de trabalho

Em vez de gerenciar pools e provedores de identidade de carga de trabalho em vários projetos, use um único projeto dedicado para gerenciar pools e provedores de identidade da carga de trabalho. Usar um projeto dedicado ajuda você a:

Garanta que apenas provedores de identidade confiáveis sejam usados para a federação de identidade da carga de trabalho.
Controle de modo centralizado o acesso à configuração de pools e provedores de identidade da carga de trabalho.
Aplique mapeamentos e condições de atributos consistentes em todos os projetos e aplicativos.

É possível usar restrições de políticas organizacionais para aplicar a disciplina ao usar um projeto dedicado para gerenciar pools e provedores de identidade de carga de trabalho.

Usar restrições da política da organização para desativar a criação de provedores de pools de Identidades de cargas de trabalho em outros projetos

Os usuários com permissão para criar provedores de pools de identidade de cargas de trabalho podem criar pools e provedores de identidades de carga de trabalho que podem ser redundantes para aqueles que você gerencia em um projeto dedicado.

Para impedir a criação de novos provedores de pools de identidades de carga de trabalho, use a restrição de política organizacional constraints/iam.workloadIdentityPoolProviders com uma regra definida como Negar.

Aplique essas restrições na raiz da hierarquia organizacional para negar a criação de novos provedores de pools de identidades de carga de trabalho por padrão. Crie exceções para os projetos em que você quer permitir o gerenciamento de pools e provedores de identidade da carga de trabalho aplicando uma restrição de política que permita determinados provedores de contas da AWS ou do OIDC.

Use um único provedor por pool de identidade da carga de trabalho para evitar conflitos de assunto

A federação de identidade da carga de trabalho permite criar mais de um provedor por pool de identidades de carga de trabalho. O uso de vários provedores pode ser útil se as identidades forem gerenciadas por vários provedores, mas você quiser ocultar essa complexidade das cargas de trabalho em execução no Google Cloud.

O uso de vários provedores apresenta risco de colisões de assunto, em que o mapeamento de google.subject de um provedor retorna o mesmo valor do mapeamento de outro provedor. O resultado dessa colisão é que várias identidades externas são mapeadas para o mesmo principal do IAM, tornando as identidades externas indistinguíveis nos registros de auditoria do Cloud.

Para evitar conflitos de assunto, use um provedor por pool de identidade da carga de trabalho. Se você precisar federar com vários provedores, crie vários pools de identidades de carga de trabalho, cada um usando um único provedor de identidade de carga de trabalho.

Evite federar com o mesmo provedor de identidade duas vezes

É possível fazer a federação com o mesmo provedor de identidade várias vezes, criando vários provedores de pools de identidades de carga de trabalho que usam uma configuração igual ou semelhante. Se esses provedores pertencerem ao mesmo pool de identidades de carga de trabalho, essa configuração poderá levar a colisões de assunto. Se os provedores pertencerem a diferentes pools de identidades de carga de trabalho, as colisões de assunto não poderão ocorrer e a mesma identidade externa será representada como diferentes principais do IAM.

Mapear uma única identidade externa para vários principais do IAM torna mais difícil analisar a quais recursos uma identidade externa específica tem acesso. Essa ambiguidade também pode aumentar o risco ao tentar revogar o acesso: um administrador pode revogar o acesso de um principal, mas pode não estar ciente da existência de outro principal, fazendo com que a identidade externa retenha o acesso acidentalmente. de dados.

Para minimizar o risco de ambiguidades, evite federar com o mesmo provedor de identidade mais de uma vez. Em vez disso, crie um único pool e provedor de identidade de carga de trabalho e use um mapeamento e uma condição de atributo que garanta que ele possa ser usado para todas as identidades externas que exigem acesso aos recursos do Google Cloud.

Proteja o endpoint de metadados OIDC do seu provedor de identidade.

Quando você faz a federação com um provedor OpenID Connect, a federação de identidade da carga de trabalho faz o download periódico dos metadados OIDC do seu provedor de identidade. A federação de identidade da carga de trabalho usa os metadados do IdP e o conjunto de chaves da Web JSON (JWKS) para validar tokens.

Para garantir a autenticidade, a comunicação com seu provedor de identidade é protegida usando TLS. Se o provedor for implantado por trás de um balanceador de carga ou de um proxy reverso que encerra o TLS, a conexão TLS garantirá a autenticidade do balanceador de carga ou do proxy reverso, mas não do provedor de identidade real.

Um usuário de má-fé pode se beneficiar dessa configuração iniciando um ataque "man-in-the-middle" (MITM), em que ele reconfigura o balanceador de carga para permitir que ele passe solicitações JWKS para um endpoint malicioso que exibe um conjunto diferente de chaves. Trocar o JWKS permite que um usuário de má-fé assine tokens considerados válidos pela federação de identidade da carga de trabalho e que possa permitir o spoofing de identidades de outro usuário.

Para se proteger contra a troca de JWKS, verifique se o IdP foi implantado de maneira a protegê-lo contra ataques de MITM.

Usar o URL do provedor de pool de Identidade da carga de trabalho como público-alvo

Quando você faz a federação com um provedor OpenID Connect, a federação de identidade da carga de trabalho verifica se o público dos tokens (codificados na declaração aud) corresponde à configuração de público permitida do provedor. Da mesma forma, quando você faz a federação com um provedor SAML, a federação de identidade da carga de trabalho verifica se a asserção SAML especifica uma restrição de público-alvo que corresponda ao público esperado.

Por padrão, a federação de identidade da carga de trabalho espera que o público-alvo corresponda ao URL https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID que identifica exclusivamente o provedor de pools de identidades de carga de trabalho. A exigência de tokens e declarações para usar esse URL como público-alvo ajuda a reduzir o risco de um ataque de confused deputy. Nesse ataque, um usuário de má-fé apresenta uma declaração SAML ou de token para a federação de identidade da carga de trabalho que não deveria ser usada para a federação de identidade da carga de trabalho, mas para alguma outra API.

A exigência do token ou da declaração para conter o URL do provedor de pool de identidades da carga de trabalho de destino ajuda a garantir que os clientes só possam usar tokens e declarações especificamente emitidos para a federação de identidade da carga de trabalho.

Usar atributos imutáveis em mapeamentos de atributos

Para conceder permissão a uma identidade externa para personificar uma conta de serviço, crie uma vinculação do IAM que faça referência à identidade externa por assunto, grupo ou um atributo personalizado. O assunto, o grupo e os atributos personalizados da identidade externa são derivados dos atributos que o provedor de identidade externo passa para a federação de identidade da carga de trabalho durante a troca do token.

Alguns provedores de identidade permitem que os usuários alterem alguns dos atributos. Por exemplo, um usuário pode modificar o endereço de e-mail ou os aliases dele. Se as vinculações do IAM se referirem a atributos modificáveis, os usuários poderão perder acidentalmente o acesso a determinados recursos modificando o perfil de usuário. Ou pior, usuários de má-fé podem conseguir acesso não autorizado a outros recursos modificando deliberadamente os atributos de usuário para corresponder às vinculações atuais do IAM.

Para se proteger contra essa ameaça de spoofing, limite os mapeamentos de atributos aos atributos que não possam ser modificados pelo usuário ou não possam ser modificados.

Usar atributos não reutilizáveis em mapeamentos de atributos

Quando você concede uma permissão de identidade externa para personificar uma conta de serviço e, em seguida, excluir o usuário no provedor de identidade externo, a vinculação do IAM da conta de serviço permanece em vigor.

Se, depois, você adicionar um novo usuário ao seu provedor de identidade externo e ele compartilhar determinados atributos com o usuário excluído anteriormente (por exemplo, o mesmo endereço de e-mail), os usuários antigos e novos não poderão ser diferenciados para a carga de trabalho. federação de identidade. Como resultado, uma vinculação do IAM destinada apenas ao usuário antigo também pode ser aplicada ao novo usuário.

Para evitar essas ambiguidades, use mapeamentos de atributos que dependam exclusivamente de atributos que não podem ser reutilizados ao longo do tempo, como um ID de usuário único.

Se a política da empresa permitir a reutilização de atributos, como endereços de e-mail, evite usar esses atributos nos mapeamentos e use um atributo diferente, com exclusividade garantida ao longo do tempo.

Não permita que os mapeamentos de atributos sejam modificados

A federação de identidade da carga de trabalho usa mapeamentos de atributo para selecionar quais atributos fornecidos pelo provedor de identidade externo precisam ser incorporados em um token STS e como os nomes dos atributos precisam ser traduzidos. A configuração de mapeamentos de atributos é uma etapa fundamental da configuração da relação de confiança entre o provedor de identidade externo e o Google Cloud.

Os mapeamentos de atributos também são essenciais para a segurança de uso da federação de identidade da carga de trabalho: se você tiver concedido a um principal federado ou a um conjunto de principais permissão para personificar uma conta de serviço e alterar o mapeamento de atributos posteriormente, talvez você altere os usuários que têm acesso à conta de serviço.

A modificação do mapeamento de atributos requer a permissão iam.googleapis.com/workloadIdentityPoolProviders.update. Os papéis que contêm essa permissão incluem:

Proprietário (roles/owner)
Administrador de pool de Identidade da carga de trabalho do IAM (roles/iam.workloadIdentityPoolAdmin)

Se um usuário de má-fé tiver permissão para modificar os mapeamentos de atributos, ele conseguirá alterar as regras de mapeamento de forma que permita falsificar a identidade e conseguir acesso a uma conta de serviço. Para evitar modificações mal-intencionadas, verifique se apenas alguns usuários administrativos têm permissão para modificar os mapeamentos de atributos.

Considere criar um projeto do Google Cloud dedicado para gerenciar pools de identidades de carga de trabalho, o que ajuda a limitar o risco de usuários receberem acidentalmente um desses papéis em um nível superior na hierarquia de recursos.

Não dependa de atributos não estáveis ou autoritativos.

Um provedor de identidade usa atributos para comunicar informações sobre usuários autenticados. Os provedores de identidade normalmente garantem que alguns atributos sejam confiáveis, mas outros não. Por exemplo, um provedor de identidade externo pode incorporar um nome de usuário e um ID de usuário em um token OIDC. Os dois atributos identificam um usuário de maneira exclusiva e podem parecer intercambiáveis. Mas o provedor de identidade externo pode garantir que o ID do usuário seja estável e confiável, mas permite que os nomes de usuário sejam alterados.

Se os mapeamentos de atributos dependem de atributos que não são estáveis ou autoritários, um usuário de má-fé pode conseguir personificar a identidade deles modificando o perfil do usuário no provedor de identidade externo. Por exemplo, ele pode alterar o nome de usuário para o de um usuário que foi excluído recentemente no provedor de identidade externo, mas que ainda tem acesso a uma conta de serviço no Google Cloud.

Para evitar ataques de spoofing, verifique se os mapeamentos de atributos dependem apenas de atributos que o provedor de identidade externo garante que sejam estáveis e autoritários.

Proteção contra ameaças de não repúdio

Sempre que você notar atividades suspeitas afetando um dos seus recursos no Google Cloud, os registros de auditoria do Cloud são uma fonte de informação importante para descobrir quando a atividade ocorreu e quais usuários estavam envolvidos.

Quando um aplicativo usa a federação de identidade da carga de trabalho, ele falsifica a identidade de uma conta de serviço. Nos registros de auditoria do Cloud, qualquer atividade realizada pelo aplicativo é atribuída à conta de serviço representada. Para reconstruir toda a cadeia de eventos que levaram à atividade, você precisa correlacionar os registros de auditoria do Cloud com os registros do seu provedor de identidade para descobrir qual identidade externa estava envolvida, e por que uma atividade foi realizada.

Esta seção descreve as práticas recomendadas que podem ajudar você a manter uma trilha de auditoria não repudiável.

Práticas recomendadas:

Ative registros de acesso a dados para APIs IAM.
Usar um mapeamento de assunto exclusivo.

Ative registros de acesso a dados para APIs IAM

Para ajudar você a identificar e compreender cenários de personificação de conta de serviço, serviços como o Compute Engine incluem uma seção serviceAccountDelegationInfo nos registros de auditoria do Cloud. Quando um aplicativo usa a federação de identidade da carga de trabalho, esta seção inclui o assunto do principal que foi usado para personificar a conta de serviço.

Nem todos os serviços incluem detalhes de personificação de identidade nos registros de auditoria do Cloud. Para ajudar a manter uma trilha de auditoria não replicável, você também precisa registrar todos os eventos de representação ativando registros de acesso a dados para a API Security Token Service } e API Identity and Access Management. Ative esses registros para todos os projetos do Cloud que contêm pools de identidades de carga de trabalho ou contas de serviço usadas para federação de identidade de carga de trabalho.

Ao ativar esses registros, você garante que uma entrada seja adicionada aos registros de auditoria do Cloud sempre que um aplicativo usar a federação de identidade da carga de trabalho para trocar uma credencial externa e representa uma conta de serviço.

Usar um mapeamento de assunto exclusivo

O assunto principal usado na seção serviceAccountDelegationInfo nas entradas de registros de auditoria do Cloud é determinado pelo mapeamento de atributos do provedor de pools de identidades de carga de trabalho para google.subject.

Quando você detecta atividades suspeitas e precisa descobrir qual identidade externa está envolvida, é possível procurar uma identidade externa pelo valor google.subject correspondente.

Da mesma forma, quando uma identidade externa foi comprometida e você precisa descobrir se a identidade foi usada para acessar os recursos do Google Cloud, é possível encontrar entradas de registros de auditoria do Cloud que correspondam à identidade externa.

Ao definir o mapeamento de atributos de um provedor de pools de identidades de carga de trabalho, escolha um mapeamento exclusivo para google.subject para que:

Uma identidade externa é mapeada para exatamente um valor google.subject.
Um valor google.subject é mapeado para exatamente uma identidade externa.
É possível pesquisar uma identidade externa pelo valor google.subject.

O uso de um mapeamento de atributo que atenda a esses critérios de exclusividade ajuda a garantir a pesquisa de identidades externas pelo valor google.subject e vice-versa.

Como se proteger contra ameaças de escalonamento de privilégios

Para aplicar o princípio do menor privilégio ao usar a federação de identidade de carga de trabalho, você precisa:

limitar o número de identidades externas que podem representar uma conta de serviço
limitar os recursos que uma conta de serviço pode acessar

Uma configuração excessivamente permissiva pode levar a uma situação em que um usuário de má-fé pode usar uma identidade externa para escalonar os privilégios e acessar recursos a que não deveria ter acesso.

Nas seções a seguir, apresentamos as práticas recomendadas para proteger contra ameaças de escalonamento de privilégios.

Práticas recomendadas:

Use contas de serviço que estejam no mesmo projeto que os recursos que você precisa acessar.
Usar uma conta de serviço dedicada para cada aplicativo.
Evitar o acesso a todos os membros de um pool.

Use contas de serviço que estejam no mesmo projeto que os recursos que você precisa acessar.

Quando um cliente usa federação de identidade da carga de trabalho usando bibliotecas de cliente ou a API REST, ela segue um processo em três etapas:

Consiga uma credencial do provedor de identidade confiável.
Troque a credencial por um token do Security Token Service.
Use o token do Security Token Service para personificar uma conta de serviço e receber um token de acesso de curta duração do Google.

Na última etapa, use uma conta de serviço que esteja no mesmo projeto que os recursos que você precisa acessar. Usar uma conta de serviço gerenciada no mesmo projeto ajuda você a aplicar permissões de acesso mais restritivas e facilita a decisão de quando a conta de serviço pode não ser mais necessária.

Usar uma conta de serviço dedicada para cada aplicativo

Se você tiver vários aplicativos que usam a federação de identidade de carga de trabalho para acessar recursos no mesmo projeto, crie uma conta de serviço dedicada para cada aplicativo. O uso de contas de serviço específicas do aplicativo ajuda a evitar o excesso de permissões concedendo apenas o acesso aos recursos que cada aplicativo individual exige.

Evite conceder acesso a todos os membros de um pool

Antes que uma identidade externa possa personificar uma conta de serviço, você precisa conceder a ela o papel roles/iam.workloadIdentityUser na conta de serviço. Ao fazer isso, evite concedê-lo a todos os membros do pool de identidades da carga de trabalho. Em vez disso, conceda o papel a identidades externas específicas ou a identidades que correspondam a determinados critérios.

Inicialmente, o número de usuários externos que precisam de acesso aos recursos do Google Cloud pode ser pequeno. A condição do atributo do pool de identidades da carga de trabalho e a configuração do provedor de identidade, portanto, podem permitir que apenas algumas identidades externas usem a federação de identidade da carga de trabalho.

Ao integrar novas cargas de trabalho ao Google Cloud posteriormente, talvez seja necessário modificar a configuração do provedor de identidade ou a condição de atributo do pool de identidades da carga de trabalho para permitir outras identidades externas.

Ao conceder apenas o papel roles/iam.workloadIdentityUser a identidades externas específicas, você garante que será possível aumentar com segurança um pool de identidades de carga de trabalho sem conceder acidentalmente mais acesso de representação de identidades externas do que o necessário.

A seguir

Saiba mais sobre as práticas recomendadas para trabalhar com as contas de serviço.
Leia mais sobre as práticas recomendadas para gerenciar chaves de contas de serviço.