Federação de identidade da força de trabalho

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Este documento descreve os principais conceitos da federação de identidade da força de trabalho.

O que é a federação de identidade da força de trabalho?

A federação de identidade da força de trabalho permite que você use um provedor de identidade externo (IdP) para autenticar e autorizar uma força de trabalho, um grupo de usuários, como funcionários, parceiros e prestadores de serviços, usando o IAM. para que os usuários acessem os serviços do Google Cloud. Com a federação de identidade da força de trabalho, 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 da força de trabalho 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 da força de trabalho com qualquer IdP compatível com o OpenID Connect (OIDC) ou SAML 2.0, como o Azure Active Directory (Azure AD), Serviços de Federação do Active Directory (AD FS), Okta e outros.

Pools de federação da identidade da força de trabalho

Os pools de federação de identidade da força de trabalho permitem que você gerencie grupos de identidades de força de trabalho 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 da força de trabalho.

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 da força de trabalho 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 da força de trabalho

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 da força de trabalho 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.

Console de federação de identidade da força de trabalho 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 da força de trabalho.

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 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.

  • attribute.KEY (opcional): um atributo definido pelo cliente que está presente no token do IdP de um usuário. É possível usar esses atributos personalizados para definir sua estratégia de autorização em uma política de permissão do IAM. Por exemplo, é possível definir um atributo como o centro de custo do usuário: attribute.costcenter = "1234". Esse atributo poderia ser usado nas condições do IAM para conceder acesso apenas aos usuários desse centro de custos.

    É 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.

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.

Representar usuários do pool de forças de trabalho 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 força de trabalho 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 força de trabalho: principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*

Restringir o acesso entre organizações

Os principais do pool de federação da identidade da força de trabalho 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.

Para restringir o acesso de contas de serviço a recursos em outras organizações, os administradores podem configurar o VPC Service Controls. As contas de serviço criadas em um projeto que está dentro de um limite do VPC Service Controls não podem acessar recursos em projetos fora desse limite.

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

Os serviços do Google Cloud normalmente cobram pelo uso de faturamento e cota no projeto que contém os recursos (um projeto de recurso), enquanto algumas APIs do Google Cloud cobram por um projeto especificado na chamada de API. Nesses casos, um projeto de usuário do pool de federação da identidade da força de trabalho é usado para fins de faturamento e cota. O principal precisa ter a permissão serviceusage.services.use neste projeto. Se você já estiver usando os serviços do Google Cloud, poderá usar um projeto atual para fins de faturamento e cotas. Se você não tiver um projeto, poderá criar um novo. O novo projeto pode ser usado no lugar dos projetos de recursos.

Exemplo: vários pools de federação de identidade da força de trabalho

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 a força de trabalho da Organização Parceira Exemplo forneça os serviços, a força de trabalho dela precisa 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 federação de identidade da força de trabalho chamado enterprise-example-organization-employees.

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

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 força de trabalho chamado example-organization-partner.

  3. Crie a seguinte política do IAM 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 da força de trabalho 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 da força de trabalho, as APIs de configuração de pool de forças de trabalho 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.

A seguir