Federação de identidade de colaboradores

Este documento descreve os principais conceitos da federação de identidade de colaboradores.

O que é a federação de identidade de colaboradores?

A federação de identidade de colaboradores permite usar um provedor de identidade externo (IdP) para autenticar e autorizar os colaboradores que usam o IAM, como funcionários, parceiros e prestadores de serviços. Assim, os usuários podem acessar os serviços do Google Cloud. Com a federação de identidade de colaboradores, você não precisa sincronizar as identidades de usuário do seu IdP para as identidades do Google Cloud, como faria com o Google Cloud Directory Sync (GCDS) do Cloud Identity. A federação de identidade de colaboradores amplia os recursos de identidade do Google Cloud para oferecer suporte a logon único sem sincronização e baseado em atributos.

Após a autenticação do usuário, as informações recebidas do IdP são usadas para determinar o escopo de acesso aos recursos do Google Cloud.

É possível usar a federação de identidade de colaboradores com qualquer IdP compatível com o OpenID Connect (OIDC) ou SAML 2.0, como o ID do Microsoft Entra, Serviços de Federação do Active Directory (AD FS), Okta e outros.

Pools de identidade de colaboradores

Os pools de identidade de colaboradores permitem que você gerencie grupos de identidades da colaboradores e o acesso delas aos recursos do Google Cloud.

Pools permitem que você faça o seguinte:

  • Identidades de usuário de grupo por exemplo, employees ou partners
  • Conceda acesso do IAM a um pool inteiro ou a um subconjunto dele.
  • Federar identidades de um ou mais IdPs.
  • Defina políticas para um grupo de usuários que exigem permissões de acesso semelhantes.
  • Especifique informações de configuração específicas do IdP, incluindo o mapeamento de atributos e as condições de atributos.
  • Ative a CLI do Google Cloud e o acesso à API para identidades de terceiros.
  • Acesso de registro dos usuários em um pool aos registros de auditoria do Cloud, além do ID do pool.

É possível criar vários pools. Para ver um exemplo que descreve uma dessas abordagens, consulte Exemplo: vários pools de identidade de colaboradores.

Os pools são configurados no nível da organização do Google Cloud. Por isso, os pools estão disponíveis em todos os projetos e pastas na organização, desde que você tenha as permissões apropriadas do IAM para visualizar o pool. Ao configurar a federação de identidade de colaboradores para sua organização pela primeira vez, você fornece um nome para o pool. Nas políticas de permissão do IAM, você faz referência ao pool pelo nome. Por isso, recomendamos nomear o pool para que ele descreva claramente as identidades que ele contém.

Provedores de pool de identidade de colaboradores

Um provedor de pool de identidade da força de trabalho é uma entidade que descreve uma relação entre sua organização do Google Cloud e seu IdP.

A federação de identidade de colaboradores segue a especificação OAuth 2.0 Token Exchange (RFC 8693). Você fornece uma credencial do seu provedor de identidade externo ao serviço de token de segurança, que verifica a identidade da credencial e retorna um token de acesso do Google Cloud de curta duração em troca.

Tipos de fluxo do OIDC

Para provedores do OIDC, a federação de identidade de colaboradores é compatível com fluxo do código de autorização e o fluxo implícito. O fluxo do código de autorização é considerado o mais seguro, porque os tokens são retornados do IdP em uma transação de back-end segura e separada, diretamente do IdP para o Google Cloud, depois que os usuários são autenticados. Dessa forma, as transações do fluxo de códigos podem recuperar tokens de qualquer tamanho e você consegue ter mais declarações para usar para mapeamento de atributo e condição de atributo. No fluxo implícito, comparativamente, o token de ID é retornado do IdP para o navegador. Os tokens estão sujeitos aos limites individuais de tamanho de URL do navegador.

Console da federação de identidade de colaboradores do Google Cloud

Os usuários em um conjunto de identidades da força de trabalho podem acessar o console de federação de identidade da força de trabalho do Google Cloud, também conhecido como console (federado). O console fornece a esses usuários acesso à IU para produtos do Google Cloud compatíveis com a federação de identidade de colaboradores.

Mapeamentos de atributos

Seu IdP fornece atributos, chamados por alguns IdPs como reivindicações. Os atributos contém informações sobre os usuários. É possível mapear esses atributos para uso pelo Google Cloud usando a Common Expression Language (CEL).

Nesta seção, descrevemos o conjunto de atributos obrigatórios e opcionais fornecidos pelo Google Cloud.

Também é possível definir atributos personalizados no seu IdP que podem ser usados por produtos específicos do Google Cloud. por exemplo, nas políticas de permissão do IAM.

O tamanho máximo para mapeamentos de atributos é de 4 KB.

Os atributos são os seguintes:

  • google.subject (obrigatório): um identificador exclusivo para o usuário autenticador. Geralmente, ela é a declaração de assunto do JWT, porque os registros de auditoria do Cloud registram o conteúdo desse campo como o principal. Você pode usar esse campo para configurar o IAM para decisões de autorização. Recomendamos que você não use um valor mutável porque, se mudar o valor no diretório de usuário do IdP, o usuário perderá o acesso.

    O comprimento máximo é de 127 bytes.

  • google.groups (opcional): a coleção de grupos de que o usuário que faz a autenticação é membro. É possível configurar uma expressão lógica usando um subconjunto de CEL que produz uma matriz de strings. Também é possível usar esse campo para configurar o IAM para decisões de autorização. As limitações para google.groups são as seguintes:

    • Recomendamos limitar o nome do grupo a 100 caracteres.

    • Se um usuário estiver associado a mais de 100 grupos, defina um conjunto menor e inclua-os apenas em declarações usadas para federar o usuário para o Google Cloud. Se um usuário pertencer a mais de 100 grupos, a autenticação vai falhar.

    • Se você usar esse atributo para conceder acesso no IAM, todos os membros nos grupos mapeados terão acesso. Portanto, recomendamos garantir que apenas usuários autorizados na organização possam modificar a associação dos grupos mapeados.

  • google.display_name (opcional): atributo que é usado para definir o nome do usuário conectado no Console do Google Cloud. Esse atributo não pode ser usado nas políticas de permissão do IAM nem na condição do atributo.

    O comprimento máximo é de 100 bytes.

  • google.profile_photo (opcional): é um URL da foto da miniatura do usuário. Recomendamos que a foto seja de 400x400 pixels. Quando esse atributo é definido, a imagem fica visível como a foto do perfil do usuário no console do Google Cloud. Se esse valor não for definido ou não puder ser buscado, um ícone de usuário genérico será exibido. Esse atributo não pode ser usado nas políticas de permissão do IAM ou na condição do atributo.

  • google.posix_username (opcional): uma string de nome de usuário exclusiva compatível com POSIX usada para:

    Esse atributo não pode ser usado nas políticas de permissão do IAM ou na condição do atributo. O tamanho máximo é de 32 caracteres.

  • attribute.KEY (opcional): um atributo externo definido pelo IdP que está presente no token do IdP de um usuário. É possível usar o atributo personalizado para definir sua estratégia de autorização em uma política de permissão do IAM.

    Por exemplo, no IdP, é possível definir um atributo como o centro de custo do usuário como costcenter = "1234" e, em seguida, fazer referência ao princípio da seguinte maneira:

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.costcenter/1234

    Depois de conceder acesso aos recursos do Google Cloud a esse identificador principal, todas as identidades configuradas no IdP para ter o atributo costcenter definido como 1234 terão acesso aos recursos.

    É possível configurar até 50 regras personalizadas de mapeamento de atributos. O tamanho máximo de cada regra é 2.048 caracteres.

    Não temos restrições quanto aos atributos que podem ser mapeados aqui, mas recomendamos que você escolha atributos com valores estáveis. Por exemplo, um atributo como attribute.job_description pode mudar por vários motivos (por exemplo, para melhorar a legibilidade). Como alternativa, use attribute.role. Essas alterações indicam uma mudança na responsabilidade atribuída e se alinham às mudanças no acesso concedido ao usuário.

É possível transformar valores dos atributos usando funções CEL padrão. Você também pode usar as seguintes funções personalizadas:

  • A função split divide uma string no valor do separador fornecido. Por exemplo, para extrair o atributo username de um atributo de endereço de e-mail dividindo o valor no @ e usando a primeira string, use o seguinte mapeamento de atributo: 

    attribute.username=assertion.email.split("@")[0]

  • A função join mescla uma lista de strings no valor do separador fornecido. Por exemplo, para preencher o atributo personalizado department concatenando uma lista de strings com . como separador, use o seguinte mapeamento de atributo: 

    attribute.department=assertion.department.join(".")

Condições do atributo

As condições do atributo são expressões CEL opcionais que permitem definir restrições nos atributos de identidade aceitos pelo Google Cloud.

Os benefícios de usar condições de atributos incluem o seguinte:

  • É possível usar condições de atributos para permitir que apenas um subconjunto de identidades externas sejam autenticadas no seu projeto do Google Cloud. Por exemplo, é recomendável permitir que apenas as identidades de uma equipe específica façam login, especialmente se você estiver usando um IdP público. Em outro exemplo, talvez você queira permitir que a equipe de contabilidade faça login, mas não a equipe de engenharia.
  • As condições do atributo permitem 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.

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

A federação de identidade de colaboradores 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 reivindicações são mapeadas para o mesmo valor google.subject, os dois tokens são considerados como identificando o mesmo usuário. Para descobrir qual IdP emitiu um token, a federação de identidade de colaboradores inspeciona e verifica o URL do emissor do token.

Os IdPs multilocatários, 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 de colaboradores 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. Se o IdP multilocatário tiver um único URL do emissor, recomendamos que você use condições de atributo para garantir que o acesso seja restrito ao locatário correto.

Representar usuários do pool de colaboradores nas políticas do IAM

A tabela a seguir mostra os principais identificadores usados para conceder papéis a um único usuário, um grupo de usuários, aqueles que carregam uma declaração específica ou todos os usuários de um pool de forças de trabalho.

Identidades Formato do identificador
Identidade única em um pool de identidades de carga de trabalho principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
Todas as identidades de colaboradores em um grupo principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP_ID
Todas as identidades com um valor de atributo específico principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
Todas as identidades em um pool de Identidades de colaboradores: principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*

Chaves da Web JSON

O provedor do pool de identidades de carga de trabalho pode acessar chaves JSON da Web (JWKs) fornecidas pelo IdP no campo jwks_uri no documento /.well-known/openid-configuration. Se o provedor OIDC não fornecer essas informações ou o emissor não estiver acessível publicamente, será possível fazer o upload manual dos JWKs ao criar ou atualizar o provedor OIDC.

Restringir o acesso entre organizações

Os principais do pool de identidade de colaboradores não podem acessar diretamente recursos fora da organização a que pertencem. No entanto, se um principal tiver permissão para personificar uma conta de serviço na organização, essa restrição poderá ser ignorada, porque as contas de serviço não são igualmente restritas.

Projeto do usuário de pools de forças de trabalho

Na maioria das APIs do Google Cloud, o faturamento e o uso de cotas são cobrados para o projeto que contém o recurso que sua solicitação de API acessa. Elas são chamadas de APIs baseadas em recursos. Algumas APIs do Google Cloud são cobradas do projeto associado ao cliente, chamadas de APIs baseadas no cliente. O projeto usado para faturamento e cota é chamado de projeto de cota.

Ao criar um arquivo de configuração da federação de identidade de colaboradores, você especifica um projeto de usuário dos pools de colaboradores. Esse projeto é usado para identificar seu aplicativo para as APIs do Google que ele chama. O projeto de usuário dos pools de colaboradores também é usado como o projeto de cota padrão para APIs baseadas em cliente, a menos que você use a gcloud CLI para iniciar a solicitação de API. Você precisa ter a permissão serviceusage.services.use, incluída no papel Consumidor do Service Usage (roles/serviceusage.serviceUsageConsumer), para o projeto especificado.

Para mais informações sobre o projeto de cota, as APIs baseadas em recursos e APIs baseadas em cliente, consulte Informações gerais do projeto de cota.

Exemplo: vários pools de identidade de colaboradores

Nesta seção, há um exemplo que ilustra o uso típico de vários pools.

É possível criar um pool para funcionários e outro para parceiros. Organizações multinacionais podem criar pools separados para diferentes divisões. Os pools permitem o gerenciamento distribuído, em que diferentes grupos podem gerenciar de maneira independente o pool específico em que os papéis são concedidos apenas às identidades no pool.

Por exemplo, suponha que uma empresa chamada Organização Exemplo tem um contrato com outra empresa chamada Organização Parceira Exemplo Inc. para fornecer serviços de DevOps do Google Kubernetes Engine (GKE). Para que os colaboradores da Organização Parceira Exemplo forneçam os serviços, eles precisam ter permissão para acessar o Google Kubernetes Engine (GKE) e outros recursos do Google Cloud na organização da Organização Exemplo. A Organização Exemplo já tem um pool de identidade de colaboradores chamado enterprise-example-organization-employees.

Para que a Organização Parceira de Exemplo gerencie o acesso aos recursos da Organização Empresa de Exemplo, essa organização cria um pool de colaboradores separado para os usuários da colaboradores da Organização Parceira de Exemplo para que seja gerenciada. A Organização Exemplo fornece o pool de colaboradores a um administrador da Organização Parceira Exemplo. O administrador da Organização Parceira Exemplo usa o próprio IdP para conceder acesso aos colaboradores.

Para fazer isso, o administrador da Organização Exemplo executa as seguintes tarefas:

  1. Crie uma identidade como partner-organization-admin@example.com para o administrador da Organização Parceira Exemplo no IdP da Organização Exemplo, que já está configurado no pool chamado enterprise-example-organization-employees.

  2. Crie um novo pool de colaboradores chamado example-organization-partner.

  3. Crie a seguinte política de permissão para o pool example-organization-partner:

    {
  "bindings": [
    {
      "role": "roles/iam.workforcePoolEditor",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/enterprise-example-organization-employees/subject/partner-organization-admin@example.com"
      ]
    }
  ]
}

  4. Conceda papéis para o pool example-organization-partner nos recursos a que precisam acessar na Organização Exemplo.

Agora o administrador da Organização Parceira Exemplo pode configurar o pool example-organization-partner para se conectar ao IdP. Assim, eles podem permitir que a força de trabalho da Organização Parceira Exemplo faça login com as credenciais do IdP. Após o login, os usuários colaboradores da Organização Parceira Exemplo podem acessar os recursos do Google Cloud, restringidos por políticas definidas pela Organização Exemplo.

Gerenciamento de acesso facilitado

Em grandes empresas, os administradores de TI geralmente criam grupos de segurança como parte de um modelo de controle de acesso de práticas recomendadas. Os grupos de segurança controlam o acesso a recursos internos. Além disso, as empresas muitas vezes criam grupos adicionais para funcionários e outros grupos para parceiros para estender esse modelo de controle de acesso a recursos de nuvem. Isso pode resultar em proliferação de grupos profundamente aninhados, que podem se tornar muito difíceis de gerenciar.

Sua organização também pode ter políticas que limitam o número de grupos que podem ser criados para manter a hierarquia do diretório de usuários razoavelmente simples. Uma solução melhor para evitar a configuração incorreta das políticas do IAM e limitar o crescimento de grupos é usar vários pools para criar uma separação mais ampla de usuários de diferentes unidades organizacionais, unidades de negócios e organizações parceiras. É possível fazer referência a esses pools e grupos para definir políticas de IAM. Veja exemplos na etapa de configuração do IAM.

Limitações do VPC Service Controls

A federação de identidade de colaboradores, as APIs de configuração de pool de colaboradores e as APIs de serviço de token de segurança não são compatíveis com o VPC Service Controls. No entanto, os produtos do Google Cloud que os usuários do pool de forças de trabalho podem acessar são compatíveis com o VPC Service Controls. Para saber mais, consulte a página Produtos e limitações compatíveis do VPC Service Controls.

Federação de identidade de colaboradores e contatos essenciais

Para receber informações importantes sobre mudanças na sua organização ou nos produtos do Google Cloud, forneça os Contatos essenciais ao usar a federação de identidade de colaboradores. É possível entrar em contato com os usuários do Cloud Identity usando o endereço de e-mail do Cloud Identity, mas os usuários da federação de identidade de colaboradores são contatados usando os contatos essenciais.

Ao usar o console do Google Cloud para criar ou gerenciar pools de identidade da força de trabalho, você verá um banner que solicita a configuração de um contato essencial com o Jurídico e Suspensão categoria. Como alternativa, você pode definir um contato na categoria All, se não tiver contatos separados. O fornecimento dos contatos removerá o banner.

A seguir