Federação de identidade da carga de trabalho

Neste documento, você encontra uma visão geral da federação de identidade das cargas de trabalho externas. Usando a federação de identidade, é possível conceder às cargas de trabalho locais ou em várias nuvens acesso aos recursos do Google Cloud, sem usar uma chave de conta de serviço.

É possível usar a federação de identidade com a Amazon Web Services (AWS) ou qualquer provedor de identidade compatível com o OpenID Connect (OIDC), como o Microsoft Azure.

Por que federação de identidade?

Os aplicativos executados fora do Google Cloud costumavam usar chaves de conta de serviço para acessar os recursos do Google Cloud. As chaves de conta de serviço são credenciais avançadas e podem representar um risco de segurança quando não são gerenciadas corretamente.

A federação de identidade permite usar o gerenciamento de identidade e acesso (IAM) para conceder papéis do IAM a identidades externas, incluindo a capacidade de representar contas de serviço. Isso permite acessar diretamente os recursos usando um token de acesso de curta duração e elimina a carga de manutenção e segurança associada às chaves da conta de serviço.

Pools de identidade da carga de trabalho

Um pool de identidade da carga de trabalho é um contêiner para uma coleção de identidades externas.

Um projeto pode conter vários pools de identidade da carga de trabalho, e cada pool pode ter acesso a recursos diferentes. Isso segue o princípio do privilégio mínimo ao agrupar identidades relacionadas no mesmo pool e, em seguida, conceder a eles acesso refinado aos recursos.

Em geral, recomendamos a criação de um novo pool para cada ambiente que não seja do Google Cloud que precise acessar os recursos do Google Cloud, como ambientes de desenvolvimento, preparo ou produção.

Provedores de identidade da carga de trabalho

Um provedor de identidade da carga de trabalho é uma entidade que descreve uma relação entre o Google Cloud e um provedor de identidade externo. Estes são alguns exemplos de provedores:

  • AWS
  • Azure Active Directory
  • Active Directory local
  • Okta
  • Clusters do Kubernetes

A federação de identidade da carga de trabalho segue a especificação de troca de token do OAuth 2.0. Forneça uma credencial de um provedor de identidade externo para o Secure Token Service, que verifica a identidade na credencial e, em seguida, retorna um token federado em troca.

Mapeamentos de atributos

As credenciais geralmente incluem atributos que fornecem informações sobre a identidade declarada pela credencial, como nome, e-mail ou ID do usuário. O mapeamento de atributos aplica os atributos de um token externo a um token do Google. Isso permite que o IAM use tokens de provedores externos para autorizar o acesso aos recursos do Google Cloud.

No caso da AWS, o Google fornece mapeamentos padrão que abrangem os cenários mais comuns. Também é possível fornecer mapeamentos personalizados.

Para provedores OIDC, você fornece os mapeamentos. Para construir o mapeamento, consulte a documentação do provedor para ver uma lista de atributos nas credenciais.

O mapeamento de atributos é compatível com a Common Expression Language, que permite formular novos atributos personalizados com base na credencial externa ou tornar os atributos existentes mais legíveis. Por exemplo, o mapeamento a seguir define um atributo environment com base no fato de um Amazon Resource Name (ARN) conter :instance-profile/Production:

attribute.environment=assertion.arn.contains(":instance-profile/Production") ? "prod" : "test"

Condições do atributo

Uma condição de atributo permite restringir quais identidades podem ser autenticadas usando seu pool de identidade da carga de trabalho. Usando uma expressão CEL, é possível examinar os atributos em uma credencial de solicitação e escolher se quer permitir o acesso.

As condições do atributo são úteis em vários cenários:

  • Se sua carga de trabalho usar um provedor de identidade disponível para o público em geral, é possível restringir o acesso para que apenas as identidades escolhidas tenham acesso ao pool de identidades da carga de trabalho.

  • Se você estiver usando um provedor de identidade com várias plataformas em nuvem, poderá impedir que as credenciais destinadas ao uso com outra plataforma sejam usadas com o Google Cloud e vice-versa. Isso ajuda a evitar o problema de confused deputy.

O exemplo a seguir permite apenas solicitações de identidades que tenham um papel específico da AWS:

attribute.aws_role == "role-mapping"

Representação da conta de serviço:

O fluxo de troca de token retorna um token de acesso federado. É possível usar esse token para imitar uma conta de serviço e receber um token de acesso do OAuth 2.0 de curta duração. Com o token de acesso de curta duração, é possível chamar qualquer API do Google Cloud a que a conta de serviço tenha acesso.

Para representar uma conta de serviço, conceda à sua identidade externa o papel de Usuário da Identidade da carga de trabalho (roles/iam.workloadIdentityUser) em uma conta de serviço com os papéis exigidos pela carga de trabalho. É possível conceder um papel a todas as identidades em um pool de identidades da carga de trabalho ou a identidades externas específicas com base nos atributos delas.

Na tabela a seguir, descrevemos cenários comuns para a concessão de papéis:

Cenário Format
Identidade única principal://iam.googleapis.com/projects/project-number/locations/global/workloadIdentityPools/pool-id/subject/subject-name
Todas as identidades em um grupo principalSet://iam.googleapis.com/projects/project-number/locations/global/workloadIdentityPools/pool-id/group/group-name
Todas as identidades com um atributo definido usando o mapeamento de atributos principalSet://iam.googleapis.com/projects/project-number/locations/global/workloadIdentityPools/pool-id/attribute.attribute-name/attribute-value
Todas as identidades em um pool principalSet://iam.googleapis.com/projects/project-number/locations/global/workloadIdentityPools/pool-id/*

A seguir