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

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 identidades da força de trabalho permite-lhe usar um fornecedor de identidade (IdP) externo para autenticar e autorizar uma força de trabalho, um grupo de utilizadores, como funcionários, parceiros e contratados, através do IAM, para que os utilizadores possam aceder aos Trusted Cloud by S3NS serviços. Com a federação de identidade da força de trabalho, não precisa de sincronizar identidades de utilizadores do seu IdP existente com identidades, como faria com a Sincronização de diretórios do Google Cloud (GCDS) do Cloud ID. Trusted Cloud A federação de identidade da força de trabalho expande as capacidades de identidade do Google Cloud para suportar o Início de sessão único sem sincronização e baseado em atributos. Trusted Cloud

Após a autenticação do utilizador, as informações recebidas do IdP são usadas para determinar o âmbito do acesso aos Trusted Cloud by S3NS recursos.

Pode usar a federação de identidades da força de trabalho com qualquer IdP que suporte o OpenID Connect (OIDC) ou o SAML 2.0, como o Microsoft Entra ID, os Active Directory Federation Services (AD FS), o Okta e outros.

Workforce Identity Pools

Os Workload Identity Pools permitem-lhe gerir grupos de identidades do pessoal externo e o respetivo acesso a Trusted Cloud recursos.

Os conjuntos permitem-lhe fazer o seguinte:

  • Agrupar identidades de utilizadores; por exemplo, employees ou partners
  • Conceder acesso IAM a um conjunto completo ou a um subconjunto do mesmo.
  • Federar identidades de um ou mais IdPs.
  • Definir políticas num grupo de utilizadores que requerem autorizações de acesso semelhantes.
  • Especifique informações de configuração específicas do IdP, incluindo a mapeamento de atributos e as condições de atributos.
  • Ative o acesso à API e à CLI Google Cloud para identidades de terceiros.
  • Registar o acesso dos utilizadores num conjunto aos registos de auditoria na nuvem, juntamente com o ID do conjunto.

Pode criar vários conjuntos. Para ver um exemplo que descreve uma dessas abordagens, consulte o Exemplo: vários grupos de identidades da força de trabalho.

Os conjuntos são configurados ao Trusted Cloud nível da organização. Por este motivo, os conjuntos estão disponíveis em todos os projetos e pastas na organização, desde que tenha as autorizações de IAM adequadas para ver o conjunto. Quando configura pela primeira vez a federação de identidade da força de trabalho para a sua organização, fornece um nome para o Workload Identity Pool. Nas políticas de autorização da IAM, faz referência ao conjunto pelo respetivo nome. Por este motivo, recomendamos que atribua um nome ao conjunto para que descreva claramente as identidades que contém.

Fornecedores do Workforce Identity Pool

Um fornecedor do Workload Identity Pool é uma entidade que descreve uma relação entre a sua Trusted Cloud organização e o seu IdP.

A federação de identidade da força de trabalho segue a especificação de troca de tokens OAuth 2.0 (RFC 8693). Fornece uma credencial do seu fornecedor de identidade externo ao serviço de tokens de segurança, que valida a identidade na credencial e, em seguida, devolve um token de acesso de curta duração em troca. Trusted Cloud

Tipos de fluxo de OIDC

Para fornecedores OIDC, a federação de identidade da força de trabalho suporta o fluxo de 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 devolvidos do IdP numa transação de back-end separada e segura, diretamente do IdP para o Trusted Cloud, após a autenticação dos utilizadores. Como resultado, as transações de fluxo de código podem obter tokens de qualquer tamanho, pelo que pode ter mais reivindicações para usar no mapeamento de atributos e na condição de atributos. No fluxo implícito, por comparação, o token de ID é devolvido do IdP para o navegador. Os tokens estão sujeitos a limites de tamanho de URL do navegador individual.

Trusted Cloud Consola da federação de identidade da força de trabalho

Os utilizadores num Workforce Identity Pool podem aceder à Trusted Cloud by S3NS consola da federação de identidade da força de trabalho, também conhecida como consola (federada). A consola oferece a estes utilizadores acesso à IU dos Trusted Cloud produtos que suportam a federação de identidade da força de trabalho.

Atributos

O IdP fornece atributos, a que alguns IdPs se referem como reivindicações. Os atributos contêm informações sobre os seus utilizadores. Pode usar estes atributos em mapeamentos de atributos e condições de atributos.

Mapeamentos de atributos

Pode mapear estes atributos para utilização Trusted Cloud usando o Idioma de expressão comum (IEC).

Esta secção descreve o conjunto de atributos obrigatórios e opcionais que o Trusted Cloud oferece.

Também pode definir atributos personalizados no seu IdP que podem ser usados por produtos Trusted Cloud específicos; por exemplo, em políticas de autorização do IAM.

O tamanho máximo para mapeamentos de atributos é de 16 KB. Se o tamanho dos mapeamentos de atributos exceder o limite de 16 KB, a tentativa de início de sessão falha.

Os atributos são os seguintes:

  • google.subject (Obrigatório): um identificador exclusivo para o utilizador de autenticação. É frequentemente a afirmação do assunto do JWT, porque os registos dos registos de auditoria do Google Cloud registam o conteúdo deste campo como o principal. Pode usar este campo para configurar o IAM para decisões de autorização. Recomendamos que não use um valor mutável porque, se alterar o valor no diretório de utilizadores do seu IdP, o utilizador perde o acesso.

    O comprimento máximo é de 127 bytes.

  • google.groups (Opcional): a coleção de grupos dos quais o utilizador de autenticação é membro. Pode configurar uma expressão lógica com um subconjunto do CEL que produz uma matriz de strings. Também pode usar este campo para configurar o IAM para decisões de autorização. As limitações para google.groups são as seguintes:

    • Recomendamos que limite o nome do grupo a 40 carateres.

    • Se um único utilizador pertencer a mais de 400 grupos, a tentativa de início de sessão desse utilizador falha. Para mitigar esta situação, tem de definir um conjunto mais pequeno de grupos na declaração e mapear apenas os grupos que são usados para federar o utilizador para Trusted Cloud.

    • Se usar este atributo para conceder acesso na IAM, todos os membros nos grupos mapeados recebem acesso. Por conseguinte, recomendamos que se certifique de que apenas os utilizadores autorizados na sua organização podem modificar a associação dos grupos mapeados.

  • google.display_name (Opcional): atributo usado para definir o nome do utilizador com sessão iniciada na consola Trusted Cloud . Não é possível usar este atributo nas políticas de autorização do IAM nem na condição do atributo.

    O comprimento máximo é de 100 bytes.

  • google.profile_photo (opcional): um URL da foto em miniatura do utilizador. Recomendamos que a foto tenha 400 x 400 píxeis. Quando este atributo está definido, a imagem é visível como a imagem do perfil do utilizador na consola do Trusted Cloud . Se este valor não estiver definido ou não for possível obtê-lo, é apresentado um ícone de utilizador genérico. Não é possível usar este atributo em políticas de autorização do IAM nem na condição do atributo.

  • google.posix_username (Opcional): uma string de nome de utilizador exclusiva em conformidade com POSIX usada para o seguinte:

    Não é possível usar este atributo em políticas de autorização do IAM nem na condição de atributo. O comprimento máximo é de 32 carateres.

  • google.email (Opcional): um atributo que é usado para mapear endereços de email de utilizadores federados com sessão iniciada do IdP para produtos que integra através da integração do cliente OAuth da Workforce Identity Federation. Não é possível usar este atributo em políticas de autorização do IAM nem na condição de atributo.

    Por exemplo, para mapear endereços de email do Okta através do protocolo OIDC, inclua google.email=assertion.email no mapeamento de atributos.

    Exemplos Trusted Cloud de produtos que suportam a integração de clientes OAuth incluem o seguinte:

  • attribute.KEY (Opcional): um atributo definido pelo IdP externo que está presente no token do IdP de um utilizador. Pode usar o atributo personalizado para definir a sua estratégia de autorização numa política de autorização do IAM.

    Por exemplo, no seu IdP, pode optar por definir um atributo, como o centro de custos do utilizador, como costcenter = "1234" e, em seguida, fazer referência ao principal da seguinte forma:

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workforcePools/WORKFORCE_POOL_ID/attribute.costcenter/1234

    Depois de conceder acesso aos recursos Trusted Cloud a este identificador principal, todas as identidades configuradas no IdP para terem o atributo costcenter definido como 1234 têm acesso aos recursos.

    Pode configurar um máximo de 50 regras de mapeamento de atributos personalizados. O tamanho máximo de cada regra é de 2048 carateres.

    Embora não tenhamos restrições quanto aos atributos que pode mapear aqui, recomendamos vivamente que escolha atributos cujos valores sejam estáveis. Por exemplo, um atributo como attribute.job_description pode mudar por vários motivos (como melhorar a respetiva legibilidade). Em alternativa, considere usar attribute.role. As alterações ao último indicam uma alteração da responsabilidade atribuída e estão alinhadas com as alterações no acesso concedido ao utilizador.

Pode transformar os valores dos atributos através de funções IEC padrão. 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 email dividindo o respetivo valor no @ e usando a primeira string, use o seguinte mapeamento de atributos: 

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

  • A função join une 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 atributos: 

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

Condições de atributos

As condições de atributos são expressões CEL opcionais que lhe permitem definir restrições nos atributos de identidade que o atributo Trusted Cloud aceita.

As vantagens da utilização de condições de atributos incluem o seguinte:

  • Pode usar condições de atributos para permitir que apenas um subconjunto de identidades externas se autentique no seu projeto Trusted Cloud . Por exemplo, pode querer permitir que apenas as identidades que pertencem a uma equipa específica iniciem sessão, especialmente se estiver a usar um IdP público. Por exemplo, pode querer permitir que a sua equipa de contabilidade inicie sessão, mas não a sua equipa de engenharia.
  • As condições de atributos permitem-lhe impedir que as credenciais destinadas a utilização com outra plataforma sejam usadas com o Trusted Cloude vice-versa. Isto ajuda a evitar o problema do vice-confuso.

Use condições de atributos quando federar com o GitHub ou outros fornecedores de identidade multi-inquilinos

A federação de identidades da força de trabalho não mantém um diretório de contas de utilizador; em vez disso, implementa identidades baseadas em reivindicações. Consequentemente, quando são emitidos dois tokens pelo mesmo fornecedor de identidade (IdP) e as respetivas reivindicações são mapeadas para o mesmo valor google.subject, considera-se que os dois tokens identificam o mesmo utilizador. Para saber que IdP emitiu um token, a federação de identidade da força de trabalho inspeciona e valida o URL do emissor do token.

Os IdPs multi-inquilino, como o GitHub e o Terraform Cloud, usam um único URL do emissor em todos os respetivos inquilinos. Para estes fornecedores, o URL do emissor identifica toda a organização do GitHub ou do Terraform Cloud, e não uma organização específica do GitHub ou do Terraform Cloud.

Quando usa estes fornecedores de identidade, não é suficiente permitir que a federação de identidades da força de trabalho verifique o URL do emissor de um token para garantir que provém de uma fonte fidedigna e que as respetivas reivindicações são fidedignas. Se o seu IdP multi-inquilino tiver um único URL de emissor, recomendamos que use condições de atributos para garantir que o acesso está restrito ao inquilino correto.

Represente utilizadores do grupo de trabalhadores em políticas de IAM

A tabela seguinte mostra os identificadores principais que usa para conceder funções a um único utilizador, a um grupo de utilizadores, a utilizadores com uma determinada reivindicação ou a todos os utilizadores de um grupo do Workforce.

Identidades Formato do identificador
Identidade única num Workload Identity Pool principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
Todas as identidades da força de trabalho num grupo principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP_ID
Todas as identidades da força de trabalho com um valor de atributo específico principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
Todas as identidades num Workload Identity Pool principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*

Para ver uma lista completa de identificadores principais, consulte o artigo Identificadores principais.

Registo de auditoria detalhado

O registo de auditoria detalhado é uma funcionalidade da federação de identidade da força de trabalho que regista os atributos recebidos do seu IdP nos registos de auditoria do Cloud.

Pode ativar o registo de auditoria detalhado quando cria o fornecedor do pool de identidades da força de trabalho.

Para saber como resolver problemas de mapeamento de atributos com registo de auditoria detalhado, consulte o artigo Erros gerais de mapeamento de atributos.

Chaves Web JSON

O fornecedor do pool de força de trabalho pode aceder às chaves Web JSON (JWKs) fornecidas pelo seu IdP no campo jwks_uri do documento /.well-known/openid-configuration. Se o seu fornecedor de OIDC não fornecer estas informações ou o seu emissor não for acessível publicamente, pode carregar manualmente os JWKs quando criar ou atualizar o fornecedor de OIDC.

Restrinja o acesso entre organizações

Os principais do Workload Identity Pool não podem aceder diretamente a recursos fora da organização à qual pertencem. No entanto, se um principal tiver autorização para roubar a identidade de uma conta de serviço na organização, esta restrição pode ser ignorada, uma vez que as contas de serviço não estão igualmente restritas.

Projeto do utilizador dos conjuntos de trabalhadores

A maioria das Trusted Cloud APIs cobra a faturação e a utilização de quotas ao projeto que contém o recurso ao qual o seu pedido de API acede. Estas APIs são denominadas APIs baseadas em recursos. Algumas Trusted Cloud APIs cobram ao projeto associado ao cliente; estas são denominadas APIs baseadas no cliente. O projeto usado para fins de faturação e quotas é denominado projeto de quotas.

Quando cria um ficheiro de configuração da federação de identidade da força de trabalho, especifica um projeto do utilizador dos Workforce Pools. Este projeto é usado para identificar a sua aplicação nas APIs Google que chama. O projeto do utilizador dos workforce pools também é usado como o projeto de quota predefinido para APIs baseadas no cliente, a menos que use a CLI gcloud para iniciar o pedido API. Tem de ter a autorização serviceusage.services.use, que está incluída na função consumidor de utilização de serviços (roles/serviceusage.serviceUsageConsumer) para o projeto que especificar.

Para mais informações sobre o projeto de quota, as APIs baseadas em recursos e as APIs baseadas em clientes, consulte o artigo Vista geral do projeto de quota.

Exemplo: vários Workforce Identity Pools

Esta secção contém um exemplo que ilustra a utilização típica de vários pools.

Pode criar um conjunto para funcionários e outro para parceiros. As organizações multinacionais podem criar pools separados para diferentes divisões na respetiva organização. Os pools permitem a gestão distribuída, em que diferentes grupos podem gerir de forma independente o respetivo pool específico, onde as funções são concedidas apenas às identidades no pool.

Por exemplo, suponhamos que uma empresa denominada Enterprise Example Organization contrata uma empresa diferente denominada Partner Example Organization Inc para fornecer serviços de DevOps do Google Kubernetes Engine (GKE). Para que a força de trabalho da Partner Example Organization preste os serviços, tem de ter autorização para aceder ao Google Kubernetes Engine (GKE) e a outros recursos na organização da Enterprise Example Organization. Trusted Cloud A organização de exemplo da empresa já tem um Workload Identity Pool denominado enterprise-example-organization-employees.

Para permitir que a organização de exemplo do parceiro faça a gestão do acesso aos recursos da organização de exemplo da empresa, a organização de exemplo da empresa cria um conjunto de trabalhadores separado para os utilizadores da força de trabalho da organização de exemplo do parceiro, para que a organização de exemplo do parceiro possa geri-lo. A organização de exemplo empresarial fornece o conjunto de trabalhadores a um administrador da organização de exemplo parceira. Parceiro O administrador da organização de exemplo usa o seu próprio IdP para conceder acesso à sua força de trabalho.

Para o fazer, o administrador da organização de exemplo empresarial realiza as seguintes tarefas:

  1. Crie uma identidade, como partner-organization-admin@example.com, para o administrador da organização Partner Example na organização Enterprise Example, que já está configurada no conjunto denominado enterprise-example-organization-employees.

  2. Crie um novo workforce pool denominado example-organization-partner.

  3. Crie a seguinte política de permissão para o conjunto 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 funções para o conjunto example-organization-partner nos recursos aos quais precisam de aceder na organização da organização de exemplo empresarial.

O administrador da Partner Example Organization pode agora configurar o conjunto example-organization-partner para estabelecer ligação ao respetivo IdP. Em seguida, podem permitir que os trabalhadores da organização de exemplo do parceiro iniciem sessão com as credenciais do IdP da organização de exemplo do parceiro. Depois de iniciarem sessão, os utilizadores da força de trabalho da Partner Example Organization podem aceder a Trusted Cloud recursos, restritos por políticas definidas pela Enterprise Example Organization.

Gestão de acessos mais fácil

Em grandes empresas, os administradores de TI criam frequentemente grupos de segurança como parte de um modelo de controlo de acesso de práticas recomendadas. Os grupos de segurança regem o acesso a recursos internos. Além disso, as empresas criam frequentemente grupos adicionais para funcionários e outros grupos para parceiros, de modo a estender este modelo de controlo de acesso aos recursos na nuvem. Isto pode resultar na proliferação de grupos profundamente aninhados que podem tornar-se muito difíceis de gerir.

A sua organização também pode ter políticas que limitam o número de grupos que pode criar para manter a hierarquia do diretório de utilizadores razoavelmente simples. Uma solução melhor para evitar a configuração incorreta de políticas de IAM e limitar o crescimento de grupos é usar vários conjuntos para criar uma separação mais ampla de utilizadores de diferentes unidades organizacionais e unidades empresariais, bem como organizações parceiras. Em seguida, pode fazer referência a estes conjuntos e grupos contidos nestes conjuntos para definir políticas de IAM (consulte exemplos no passo de configuração do IAM).

Limitações dos VPC Service Controls

As funcionalidades administrativas da federação de identidade da força de trabalho, incluindo as APIs de configuração do conjunto de forças de trabalho e as APIs do serviço de tokens de segurança, não suportam os VPC Service Controls. No entanto,os Trusted Cloud produtos que suportam a Workforce Identity Federation e os VPC Service Controls funcionam conforme documentado e estão sujeitos a verificações de políticas dos VPC Service Controls. Além disso, pode usar identidades de terceiros como utilizadores do workforce pool e identidades de cargas de trabalho nas regras de entrada ou saída do VPC Service Controls.

Federação de identidade da força de trabalho e contactos essenciais

Para receber informações importantes sobre alterações à sua organização ou Trusted Cloud produtos, tem de indicar contactos essenciais quando usar a federação de identidades da força de trabalho. Os utilizadores do Cloud ID podem ser contactados através do respetivo endereço de email do Cloud ID, mas os utilizadores da Workforce Identity Federation são contactados através dos contactos essenciais.

Quando usa a Trusted Cloud consola para criar ou gerir pools de identidades da força de trabalho, é apresentado um banner que lhe pede para configurar um contacto essencial com a categoria Legal e Suspension. Em alternativa, pode definir um contacto na categoria Todos se não tiver contactos separados. Se fornecer os contactos, a faixa é removida.

O que se segue?