Configure a federação de identidades de carga de trabalho com pipelines de implementação

Este guia descreve como usar a Workload Identity Federation para permitir que os pipelines de implementação se autentiquem no Google Cloud.

Consoante o sistema de CI/CD que estiver a usar, os seus pipelines de implementação podem ter acesso a credenciais ambientais específicas do ambiente. Por exemplo:

• Os pipelines do Azure DevOps podem usar uma ligação de serviço de federação de identidade da carga de trabalho do Microsoft Entra para obter um token de ID que identifica exclusivamente o projeto do Azure DevOps.
• Os fluxos de trabalho do GitHub Actions podem obter um token OIDC do GitHub que identifica de forma exclusiva o fluxo de trabalho e o respetivo repositório.
• O GitLab SaaS permite que as tarefas de CI/CD acedam a um token de ID que identifica exclusivamente a tarefa e o respetivo projeto, ambiente e repositório.
• O Terraform Cloud pode fornecer um token OIDC à sua configuração do Terraform que identifica exclusivamente o espaço de trabalho e o ambiente.

Pode configurar os seus pipelines de implementação para usar estas credenciais para autenticar no Google Cloud através da Federação de identidades de carga de trabalho. Esta abordagem elimina o encargo de manutenção e segurança associado às chaves de contas de serviço.

Antes de começar

Configure a autenticação

Select the tab for how you plan to use the samples on this page:

Console

When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

Python

Para usar os Python exemplos nesta página num ambiente de desenvolvimento local, instale e inicialize a CLI gcloud e, em seguida, configure as Credenciais predefinidas da aplicação com as suas credenciais de utilizador.

Instale a CLI Google Cloud.

Se estiver a usar um fornecedor de identidade (IdP) externo, primeiro tem de iniciar sessão na CLI gcloud com a sua identidade federada.

If you're using a local shell, then create local authentication credentials for your user account:

gcloud auth application-default login

You don't need to do this if you're using Cloud Shell.

If an authentication error is returned, and you are using an external identity provider (IdP), confirm that you have signed in to the gcloud CLI with your federated identity.

Para mais informações, consulte Configurar o ADC para um ambiente de desenvolvimento local na Google Cloud documentação de autenticação.

Funções necessárias

Para receber as autorizações de que precisa para configurar a Workload Identity Federation, peça ao seu administrador para lhe conceder a função administrador do Workload Identity Pool (roles/iam.workloadIdentityPoolAdmin) da IAM no projeto. Para mais informações sobre a atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

Também pode conseguir as autorizações necessárias através de funções personalizadas ou outras funções predefinidas.

Em alternativa, a função básica de proprietário da IAM (roles/owner) também inclui autorizações para configurar a federação de identidades. Não deve conceder funções básicas num ambiente de produção, mas pode concedê-las num ambiente de desenvolvimento ou teste.

Prepare o IdP externo

Azure DevOps

Para permitir que um pipeline do Azure DevOps se autentique no Google Cloud, primeiro configure uma associação de serviço para o Azure Resource Manager. Esta ligação permite que o pipeline obtenha um token de ID, que pode trocar por credenciaisGoogle Cloud .

Para criar uma associação de serviço para o Azure Resource Manager, faça o seguinte:

1. No Azure DevOps, abra o projeto e aceda a Project Settings (Definições do projeto).
2. Aceda a Pipelines > Ligações de serviço.
3. Clique em Criar ligação de serviço.
4. Selecione Azure Resource Manager.
5. Clicar em Seguinte.

6. Configure as seguintes definições:

   • Tipo de identidade: Registo de apps (automático)
   • Credencial: federação de identidades da carga de trabalho

   • Nível do âmbito: subscrição.

     Tem de selecionar uma subscrição, mesmo que não planeie usar a associação de serviços para aceder aos recursos do Azure.

   • Nome da ligação de serviço: introduza um nome, como google-cloud.

7. Clique em Guardar.

Num passo posterior, vai precisar do identificador do emissor e do assunto da associação de serviços. Para procurar estes detalhes, faça o seguinte:

1. Clique na associação de serviços que acabou de criar.
2. Clique em Gerir registo de apps.
3. Selecione Gerir > Certificado e segredos > Credenciais federadas.
4. Clique na credencial federada.

5. Na página Editar uma credencial, encontre os seguintes identificadores:

   • Emissor: identifica exclusivamente a sua organização do Azure DevOps
   • Identificador do assunto: identifica de forma exclusiva a ligação ao serviço

O Azure DevOps concede automaticamente acesso na subscrição que selecionou como âmbito à entidade de serviço associada à sua nova associação de serviço. Uma vez que não planeia usar a associação de serviços para aceder aos recursos do Azure, pode revogar este acesso da seguinte forma:

1. No portal do Azure, abra a subscrição que selecionou como âmbito.
2. Aceda a Controlo de acesso (IAM) > Atribuições de funções.
3. Encontre a atribuição de função para a associação de serviço e remova-a.

GitHub Actions

Não tem de fazer alterações de configuração na sua conta do GitHub.

Depois de configurar um conjunto do Workload Identity para confiar no seu repositório do GitHub, pode permitir que os fluxos de trabalho nesse repositório usem o respetivo token OIDC do GitHub para obter credenciais Google Cloud de curta duração.

GitLab SaaS

Não precisa de fazer alterações de configuração na sua conta do GitLab.

Depois de configurar um Workload Identity Pool para confiar no seu grupo do GitLab, pode ativar a federação de identidades da força de trabalho para tarefas individuais de CI/CD.

Terraform Cloud

Não tem de fazer alterações de configuração na sua conta do Terraform Cloud.

Depois de configurar um Workload Identity Pool para confiar no Terraform Cloud, pode ativar a federação de identidades da carga de trabalho para espaços de trabalho individuais.

Configure a Workload Identity Federation

Tem de realizar estes passos para cada organização do GitHub, grupo do GitLab ou organização do Terraform Cloud.

Para começar a configurar a Workload Identity Federation, faça o seguinte:

1. In the Google Cloud console, go to the project selector page.

   Go to project selector

2. Select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.
É recomendável usar um projeto dedicado para gerir os fornecedores e os conjuntos de identidades de carga de trabalho.

Verify that billing is enabled for your Google Cloud project.

Enable the IAM, Resource Manager, Service Account Credentials, and Security Token Service APIs.

Enable the APIs

Defina um mapeamento de atributos

As credenciais específicas do ambiente do seu pipeline de implementação podem conter vários atributos e tem de decidir que atributo quer usar como identificador do assunto (google.subject) em Google Cloud.

Opcionalmente, pode mapear atributos adicionais. Em seguida, pode consultar estes atributos adicionais quando conceder acesso a recursos.

Azure DevOps

O token de ID do Azure DevOps inclui uma reivindicação sub que contém o identificador do assunto da sua associação de serviços. O identificador do assunto usa o seguinte formato:

sc://ORGANIZATION/PROJECT/CONNECTION

Use o seguinte mapeamento de atributos para mapear este identificador para google.subject:

google.subject=assertion.sub

GitHub Actions

Os mapeamentos de atributos podem usar qualquer uma das reivindicações no token OIDC do GitHub Actions. Estas chaves de reivindicação de tokens e os respetivos valores são controlados pelo GitHub. No mínimo, deve mapear google.subject para assertion.sub, que corresponde ao assunto do token OIDC do GitHub Actions:

google.subject=assertion.sub

O valor do assunto do token OIDC do GitHub Actions pode variar consoante o evento de origem. Outros atributos da reivindicação podem incluir:

• repository: contém o proprietário e o nome do repositório, por exemplo, "google/guava".

• repository_id: contém o ID exclusivo do repositório, por exemplo, "20300177".

• repository_owner: contém o proprietário, que pode ser um nome de utilizador ou o nome de uma organização do GitHub, por exemplo, "google".

• repository_owner_id: contém o ID do proprietário exclusivo, por exemplo, "1342004".

Esta lista é um subconjunto das possíveis reivindicações. Consulte a documentação do GitHub sobre reivindicações de exemplo para ver uma lista completa. Certifique-se de que mapeia todas as reivindicações que planeia usar como condições de atributos ou como parte de uma condição principalSet futura.

Importante: a utilização de campos "name", como repository e repository_owner, aumenta as probabilidades de ataques de cybersquatting e typosquatting. Se eliminar o seu repositório do GitHub ou organização do GitHub, alguém pode reivindicar esse mesmo nome e estabelecer uma identidade. Para se proteger contra esta situação, use os *_idcampos numéricos em alternativa, que são exclusivos e não podem ser reutilizados.

GitLab SaaS

Os seus mapeamentos de atributos podem usar as reivindicações incorporadas no token de ID do GitLab como atributos de origem, incluindo o seguinte:

• sub: o nome do projeto e a referência do Git, por exemplo, project_path:groupname/projectname:ref_type:branch:ref:main.
• namespace_id: o ID do grupo exclusivo.
• project_id: o ID do projeto exclusivo.
• user_id: o ID do utilizador exclusivo.
• environment: o ambiente ao qual o trabalho se aplica.
• ref_path: a referência do Git, por exemplo, refs/heads/main.

O mapeamento de atributos seguinte define google.subject como a reivindicação sub do token de ID do GitLab. Uma vez que a reivindicação sub contém o nome do projeto e a referência Git, este mapeamento permite-lhe controlar o acesso por repositório e ramificação:

google.subject=assertion.sub

Controlar o acesso por repositório e ramificação pode ser útil se determinadas ramificações (por exemplo, main) precisarem de um acesso diferente aos recursos do que outras ramificações (por exemplo, ramificações de funcionalidades).

Em alguns casos, pode ser suficiente diferenciar o acesso apenas por projeto ou grupo. Por conseguinte, o mapeamento seguinte inclui dois atributos adicionais que contêm o project_id e o namespace_id do GitLab:

google.subject=assertion.sub
attribute.project_id=assertion.project_id
attribute.namespace_id=assertion.namespace_id

Terraform Cloud

Os seus mapeamentos de atributos podem usar as reivindicações incorporadas no token OIDC do Terraform Cloud, incluindo o seguinte

• terraform_organization_id: contém o ID exclusivo da organização, por exemplo, org-xxxxxxxxxxxxxxxx.
• terraform_workspace_id: contém o ID exclusivo do espaço de trabalho, por exemplo, ws-xxxxxxxxxxxxxxxx.
• terraform_workspace_name: contém o nome a apresentar do espaço de trabalho.
• sub: contém o nome a apresentar da organização, do espaço de trabalho e da fase. Por exemplo, organization:example-org:workspace:example-workspace:run_phase:apply.

O seguinte conjunto de mapeamento de atributos define google.subject para a terraform_workspace_idreivindicação do token OIDC do Terraform Cloud:

google.subject=assertion.terraform_workspace_id

Esta associação permite-lhe controlar o acesso aos Google Cloud recursos por espaço de trabalho.

Defina uma condição de atributo

As condições de atributos são expressões CEL que podem verificar atributos de afirmação e atributos de destino. Se a condição do atributo for avaliada como true para uma determinada credencial, a credencial é aceite. Caso contrário, a credencial é rejeitada. Tem de ter um mapeamento de atributos para todos os campos de condição de atributos.

Aviso: o GitHub, o GitLab SaaS e o Terraform Cloud usam um único URL de emissor em todas as organizações, e algumas das reivindicações incorporadas nos tokens OIDC podem não ser exclusivas da sua organização. Para ajudar a proteger contra ameaças de roubo de identidade, tem de usar uma condição de atributo que restrinja o acesso a tokens emitidos pela sua organização do GitHub, grupo do GitLab ou organização do Terraform Cloud.

Azure DevOps

Opcionalmente, use uma condição de atributo para restringir o acesso a determinadas ligações de serviço. Por exemplo, a seguinte condição limita o acesso a ligações num determinado projeto do Azure DevOps:

assertion.sub.startsWith('sc://ORGANIZATION/PROJECT/')

Substitua o seguinte:

• ORGANIZATION: o nome da sua organização do Azure DevOps.
• PROJECT: o nome do seu projeto do Azure DevOps.

GitHub Actions

Use a seguinte condição de atributo para restringir o acesso a tokens emitidos pela sua organização do GitHub:

assertion.repository_owner=='ORGANIZATION'

Substitua ORGANIZATION pelo nome da sua organização do GitHub.

Opcionalmente, expanda a condição de atributo para restringir o acesso a um subconjunto de fluxos de trabalho ou ramificações. Por exemplo, a seguinte condição limita o acesso a fluxos de trabalho que usam o ramo do Git main:

assertion.repository_owner=='ORGANIZATION' && assertion.ref=='refs/heads/main'

GitLab SaaS

Use a seguinte condição de atributo para restringir o acesso a tokens emitidos pelo seu grupo do GitLab

assertion.namespace_id=='GROUP_ID'

Substitua GROUP_ID pelo ID do grupo apresentado na página inicial do seu grupo do GitLab.

Opcionalmente, expanda a condição do atributo para restringir o acesso a um subconjunto de projetos, ramificações ou ambientes. Por exemplo, a seguinte condição limita o acesso a tarefas que usam o ambiente production:

assertion.namespace_id=='GROUP_ID' && assertion.environment=='production'

Terraform Cloud

Use a seguinte condição de atributo para restringir o acesso a tokens emitidos pela sua organização do Terraform Cloud:

assertion.terraform_organization_id=='ORGANIZATION_ID'

Substitua ORGANIZATION_ID pelo ID exclusivo da sua organização, por exemplo, org-xxxxxxxxxxxxxxxx. Opcionalmente, expanda a condição de atributo para restringir o acesso a um subconjunto de fluxos de trabalho ou ramificações. Por exemplo, a seguinte condição de atributo limita o acesso a um espaço de trabalho específico:

assertion.terraform_organization_id=='ORGANIZATION_ID' && assertion.terraform_workspace_id=='WORKSPACE_ID'

Crie o Workload Identity Pool e o fornecedor

Já recolheu todas as informações necessárias para criar um Workload Identity Pool e um fornecedor:

Consola

1. Na Google Cloud consola, aceda à página Novo fornecedor e conjunto de cargas de trabalho.

   Aceda a Novo fornecedor e Workload Identity Pool

2. Em Crie um Identity Pool, introduza o seguinte:

   • Nome: nome do conjunto. O nome também é usado como ID do conjunto. Não pode alterar o ID do conjunto mais tarde.
   • Descrição: texto que descreve a finalidade do grupo.

3. Clique em Continuar.

4. Configure as definições do fornecedor:

   Azure DevOps

   • Selecione um fornecedor: OpenID Connect (OIDC).
   • Nome do fornecedor: o nome do projeto do Azure DevOps ou um nome personalizado.
   • ID do fornecedor: o nome do projeto do Azure DevOps ou um ID personalizado. Não pode alterar o ID do fornecedor mais tarde.
   • URL do emissor: o emissor da ligação de serviço que pesquisou anteriormente.

   • Públicos-alvo: selecione Públicos-alvo permitidos e cole o seguinte valor

     api://AzureADTokenExchange
     

   GitHub Actions

   • Selecione um fornecedor: OpenID Connect (OIDC).
   • Nome do fornecedor: nome do fornecedor.
   • ID do fornecedor: ID do fornecedor. Não pode alterar o ID do fornecedor mais tarde.
   • URL do emissor: https://token.actions.githubusercontent.com/
   • Públicos-alvo: público-alvo predefinido

   GitLab SaaS

   • Selecione um fornecedor: OpenID Connect (OIDC).
   • Nome do fornecedor: nome do fornecedor.
   • ID do fornecedor: ID do fornecedor. Não pode alterar o ID do fornecedor mais tarde.
   • URL do emissor: https://gitlab.com
   • Públicos-alvo: público-alvo predefinido

   Terraform Cloud

   • Selecione um fornecedor: OpenID Connect (OIDC).
   • Nome do fornecedor: nome do fornecedor.
   • ID do fornecedor: ID do fornecedor. Não pode alterar o ID do fornecedor mais tarde.
   • URL do emissor: https://app.terraform.io
   • Públicos-alvo: público-alvo predefinido

5. Clique em Continuar.

6. Em Configurar atributos do fornecedor, adicione os mapeamentos de atributos que identificou anteriormente.

7. Em Condições de atributos, introduza a condição de atributo que identificou anteriormente.

8. Clique em Guardar para criar o Workload Identity Pool e o fornecedor.

gcloud

1. Crie um novo Workload Identity Pool:

   gcloud iam workload-identity-pools create POOL_ID \
       --location="global" \
       --description="DESCRIPTION" \
       --display-name="DISPLAY_NAME"
   

   Substitua os seguintes valores:

   • POOL_ID: o ID exclusivo do conjunto
   • DISPLAY_NAME: o nome da piscina
   • DESCRIPTION: a descrição da piscina. Esta descrição é apresentada quando concede acesso a identidades de pool

2. Adicione um fornecedor do Workload Identity Pool:

   Azure DevOps

   gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
       --location="global" \
       --workload-identity-pool="POOL_ID" \
       --issuer-uri="ISSUER" \
       --allowed-audiences="api://AzureADTokenExchange" \
       --attribute-mapping="MAPPINGS" \
       --attribute-condition="CONDITIONS"
   

   Substitua os seguintes valores:

   • PROVIDER_ID: o nome do projeto do Azure DevOps ou um ID personalizado para o fornecedor.
   • POOL_ID: o ID do conjunto
   • ISSUER: o emissor da ligação de serviço que pesquisou anteriormente.
   • MAPPINGS: uma lista separada por vírgulas de mapeamentos de atributos que identificou anteriormente
   • CONDITIONS: a condição do atributo que identificou anteriormente

   GitHub Actions

   gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
       --location="global" \
       --workload-identity-pool="POOL_ID" \
       --issuer-uri="https://token.actions.githubusercontent.com/" \
       --attribute-mapping="MAPPINGS" \
       --attribute-condition="CONDITIONS"
   

   Substitua os seguintes valores:

   • PROVIDER_ID: o ID exclusivo do fornecedor
   • POOL_ID: o ID do conjunto
   • MAPPINGS: uma lista separada por vírgulas de mapeamentos de atributos que identificou anteriormente
   • CONDITIONS: a condição do atributo que identificou anteriormente

   GitLab SaaS

   gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
       --location="global" \
       --workload-identity-pool="POOL_ID" \
       --issuer-uri="https://gitlab.com" \
       --attribute-mapping="MAPPINGS" \
       --attribute-condition="CONDITIONS"
   

   Substitua os seguintes valores:

   • PROVIDER_ID: o ID exclusivo do fornecedor
   • POOL_ID: o ID do conjunto
   • MAPPINGS: uma lista separada por vírgulas de mapeamentos de atributos que identificou anteriormente
   • CONDITIONS: a condição do atributo que identificou anteriormente

   Terraform Cloud

   gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
       --location="global" \
       --workload-identity-pool="POOL_ID" \
       --issuer-uri="https://app.terraform.io" \
       --attribute-mapping="MAPPINGS" \
       --attribute-condition="CONDITIONS"
   

   Substitua os seguintes valores:

   • PROVIDER_ID: o ID exclusivo do fornecedor.
   • POOL_ID: o ID do conjunto.
   • MAPPINGS: uma lista separada por vírgulas de mapeamentos de atributos que identificou anteriormente.
   • CONDITIONS: a condição do atributo que identificou anteriormente.

Nota: o prefixo gcp- está reservado e não pode ser usado num ID do fornecedor ou de um conjunto.

Atualize a condição do atributo num fornecedor de identidade de carga de trabalho

Esta secção descreve como pode atualizar a condição do atributo num fornecedor do Workload Identity Pool existente para restringir o acesso a tokens emitidos pela sua organização do GitHub, grupo do GitLab ou organização do Terraform Cloud.

Para encontrar a condição de atributo recomendada para o seu pipeline, consulte o artigo Defina uma condição de atributo.

Consola

1. Na Google Cloud consola, aceda à página Workload Identity Pools.

   Aceda aos Workload Identity Pools

2. Encontre o Workload Identity Pool que contém o fornecedor e, de seguida, clique no ícone Expand node para o pool.

3. Encontre o fornecedor do Workload Identity Pool que quer editar e clique em Editar.

4. Em Condições de atributos, introduza a condição de atributo que identificou anteriormente.

5. Para atualizar o Workload Identity Pool e o fornecedor, clique em Guardar.

gcloud

Para atualizar o fornecedor do Workload Identity Pool, execute o seguinte comando:

gcloud iam workload-identity-pools providers update-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --attribute-condition="CONDITIONS"

Substitua os seguintes valores:

• PROVIDER_ID: o ID exclusivo do fornecedor
• POOL_ID: o ID do conjunto
• CONDITIONS: a condição do atributo que identificou anteriormente

Autentique um pipeline de implementação

Tem de realizar estes passos para cada fluxo de trabalho do GitHub Actions ou espaço de trabalho do Terraform Cloud.

Permita que a sua carga de trabalho externa aceda aos recursos do Google Cloud

Para concluir as instruções mais adiante neste guia, tem de configurar a representação da conta de serviço, conforme descrito nesta secção.

Para dar acesso aos recursos à sua carga de trabalho, recomendamos que conceda acesso direto aos recursos ao principal. Google Cloud Neste caso, o principal é o utilizador federado. Alguns Google Cloud produtos têm limitações da API Google Cloud. Se a sua carga de trabalho chamar um ponto final da API que tenha uma limitação, pode, em alternativa, usar a representação de contas de serviço. Neste caso, o principal é a Google Cloud conta de serviço, que funciona como a identidade. Concede acesso à conta de serviço no recurso.

Acesso direto aos recursos

Pode conceder acesso a uma identidade federada diretamente nos recursos através da Google Cloud consola ou da CLI gcloud.

Consola

Para usar a Google Cloud consola para conceder funções de IAM diretamente num recurso, tem de aceder à página do recurso e, em seguida, conceder a função. O exemplo seguinte mostra como aceder à página do Cloud Storage e conceder a função Storage Object Viewer (roles/storage.objectViewer) a uma identidade federada diretamente num contentor do Cloud Storage.

1. Na Google Cloud consola, aceda à página Recipientes do Cloud Storage.
   

   Aceda aos contentores

2. Na lista de contentores, clique no nome do contentor para o qual quer conceder a função.

3. Selecione o separador Autorizações junto à parte superior da página.

4. Clique no botão Conceder acesso.

   É apresentada a caixa de diálogo Adicionar responsáveis.

5. No campo Novos responsáveis, introduza uma ou mais identidades que precisam de acesso ao seu contentor.

   Por assunto

   principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT
   

   Substitua o seguinte:

   • PROJECT_NUMBER: o número do projeto
   • POOL_ID: o ID do conjunto de trabalhos
   • SUBJECT: o indivíduo assunto mapeado a partir do seu IdP, por exemplo, [e-mail]

   Por grupo

   principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP
   

   Substitua o seguinte:

   • PROJECT_NUMBER: o número do projeto
   • WORKLOAD_POOL_ID: o ID do conjunto de trabalhos
   • GROUP: o grupo mapeado a partir do seu IdP, por exemplo: [e-mail]

   Por atributo

   principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
   

   Substitua o seguinte:

   • PROJECT_NUMBER: o número do projeto
   • WORKLOAD_POOL_ID: o ID do conjunto de trabalhos
   • ATTRIBUTE_NAME: um dos atributos mapeados a partir do seu IdP
   • ATTRIBUTE_VALUE: o valor do atributo

6. Selecione uma ou mais funções no menu pendente Selecionar uma função. As funções que selecionar aparecem no painel com uma breve descrição das autorizações que concedem.

7. Clique em Guardar.

gcloud

Para usar a CLI gcloud para conceder funções de IAM num recurso num projeto, faça o seguinte:

1. Obtenha o número do projeto no qual o recurso está definido.

   gcloud projects describe $(gcloud config get-value core/project) --format=value\(projectNumber\)
   

2. Conceder acesso ao recurso.

   Para usar a CLI gcloud para conceder a função Storage Object Viewer (roles/storage.objectViewer) a identidades externas que cumprem determinados critérios, execute o seguinte comando.

   Por assunto

   gcloud storage buckets add-iam-policy-binding BUCKET_ID \
       --role=roles/storage.objectViewer \
       --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"

   Por grupo

   gcloud storage buckets add-iam-policy-binding BUCKET_ID \
       --role=roles/storage.objectViewer \
       --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"

   Por atributo

   gcloud storage buckets add-iam-policy-binding BUCKET_ID \
       --role=roles/storage.objectViewer \
       --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"

   Substitua o seguinte:

   • BUCKET_ID: o contentor no qual conceder acesso
   • PROJECT_NUMBER: o número do projeto. do projeto que contém o Workload Identity Pool
   • POOL_ID: o ID do Workload Identity Pool
   • SUBJECT: o valor esperado para o atributo que mapeou para google.subject
   • GROUP: o valor esperado para o atributo que mapeou para google.groups
   • ATTRIBUTE_NAME: o nome de um atributo personalizado no mapeamento de atributos
   • ATTRIBUTE_VALUE: o valor do atributo personalizado no mapeamento de atributos

   Pode conceder funções em qualquer Google Cloud recurso que suporte políticas de autorização do IAM.

   Nota: tem de usar o número do projeto e não o ID do projeto no identificador do membro.

Simulação de identidade de conta de serviço

1. Para criar uma conta de serviço para a carga de trabalho externa, faça o seguinte:

   1. Enable the IAM, Security Token Service, and Service Account Credentials APIs.

      Enable the APIs

   2. Crie uma conta de serviço que represente a carga de trabalho. Recomendamos que use uma conta de serviço dedicada para cada carga de trabalho. A conta de serviço não tem de estar no mesmo projeto que o conjunto de identidades de carga de trabalho, mas tem de fazer referência ao projeto que contém a conta de serviço.

   3. Conceda acesso à conta de serviço aos recursos aos quais quer que as identidades externas acedam.

2. Para permitir que a identidade federada use a identidade da conta de serviço, faça o seguinte:

Consola

Para usar a Google Cloud consola para conceder funções do IAM a uma identidade federada com uma conta de serviço, faça o seguinte:

Conta de serviço no mesmo projeto

1. Para conceder acesso através da representação da conta de serviço para uma conta de serviço no mesmo projeto, faça o seguinte:

   1. Aceda à página Workload Identity Pools.

      Aceda aos Workload Identity Pools

   2. Selecione Conceder acesso.

   3. Na caixa de diálogo Conceder acesso à conta de serviço, selecione Conceder acesso através da simulação da conta de serviço.

   4. Na lista Contas de serviço, selecione a conta de serviço para as identidades externas se fazerem passar por ela e faça o seguinte:

   5. Para escolher que identidades no conjunto podem roubar a identidade da conta de serviço, execute uma das seguintes ações:

      • Para permitir que apenas identidades específicas do conjunto de identidades da carga de trabalho se façam passar pela conta de serviço, selecione Apenas identidades que correspondam ao filtro.

      • Na lista Nome do atributo, selecione o atributo pelo qual quer filtrar.

      • No campo Valor do atributo, introduza o valor esperado do atributo; por exemplo, se usar um mapeamento de atributos google.subject=assertion.sub, defina o nome do atributo como subject e o valor do atributo como o valor da reivindicação sub em tokens emitidos pelo seu fornecedor de identidade externo.

   6. Para guardar a configuração, clique em Guardar e, de seguida, em Ignorar.

Conta de serviço num projeto diferente

Nota: as contas de serviço de projetos diferentes não aparecem na secção "CONTAS DE SERVIÇO ASSOCIADAS" do seu Workload Identity Pool.

1. Para conceder acesso através da representação de conta de serviço a uma conta de serviço num projeto diferente, faça o seguinte:

   1. Aceda à página Contas de serviço.

      Aceda a Contas de serviço

   2. Selecione a conta de serviço que quer roubar.

   3. Clique em Gerir acesso.

   4. Clique em Adicionar principal.

   5. No campo Novo principal, introduza um dos seguintes identificadores principais para as identidades no seu conjunto que vão roubar a identidade da conta de serviço.

      Por assunto

      principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT
      

      Substitua o seguinte:

      • PROJECT_NUMBER: o número do projeto
      • POOL_ID: o ID do conjunto de trabalhos
      • SUBJECT: o indivíduo assunto mapeado a partir do seu IdP, por exemplo, [e-mail]

      Por grupo

      principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP
      

      Substitua o seguinte:

      • PROJECT_NUMBER: o número do projeto
      • WORKLOAD_POOL_ID: o ID do conjunto de trabalhos
      • GROUP: o grupo mapeado a partir do seu IdP, por exemplo: [e-mail]

      Por atributo

      principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
      

      Substitua o seguinte:

      • PROJECT_NUMBER: o número do projeto
      • WORKLOAD_POOL_ID: o ID do conjunto de trabalhos
      • ATTRIBUTE_NAME: um dos atributos mapeados a partir do seu IdP
      • ATTRIBUTE_VALUE: o valor do atributo

      Por piscina

      principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/*
      

      Substitua o seguinte:

      • PROJECT_NUMBER: o número do projeto
      • WORKLOAD_POOL_ID: o ID do conjunto de trabalhos

   6. Em Selecionar uma função, selecione a função de utilizador da identidade de carga de trabalho (roles/iam.workloadIdentityUser).

   7. Para guardar a configuração, clique em Guardar.

gcloud

Para conceder a função Workload Identity User (roles/iam.workloadIdentityUser) a um conjunto de principais ou um principal federado, execute o seguinte comando. Para saber mais sobre os identificadores de principais da federação de identidades da carga de trabalho, consulte o artigo Tipos de principais.

Por assunto

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"

Por grupo

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"

Por atributo

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"

Substitua o seguinte:

• SERVICE_ACCOUNT_EMAIL: o endereço de email da conta de serviço
• PROJECT_NUMBER: o número do projeto. do projeto que contém o Workload Identity Pool
• POOL_ID: o ID do Workload Identity Pool
• SUBJECT: o valor esperado para o atributo que mapeou para google.subject
• GROUP: o valor esperado para o atributo que mapeou para google.groups
• ATTRIBUTE_NAME: o nome de um atributo personalizado no mapeamento de atributos
• ATTRIBUTE_VALUE: o valor do atributo personalizado no mapeamento de atributos

Nota: tem de usar o número do projeto e não o ID do projeto no identificador do membro.

Configure a pipeline de implementação

Esta secção descreve como usar a Workload Identity Federation no seu pipeline de implementação. As instruções nesta secção partem do princípio de que as suas cargas de trabalho usam a simulação de contas de serviço para aceder a recursos. Google Cloud

Azure DevOps

Edite o ficheiro azure-pipelines.yml e adicione o seguinte à configuração do trabalho:

variables:
- name: Azure.WorkloadIdentity.Connection
  value: CONNECTION
- name: GoogleCloud.WorkloadIdentity.ProjectNumber
  value: PROJECT_NUMBER
- name: GoogleCloud.WorkloadIdentity.Pool
  value: POOL_ID
- name: GoogleCloud.WorkloadIdentity.Provider
  value: PROVIDER_ID
- name: GoogleCloud.WorkloadIdentity.ServiceAccount
  value: SERVICE_ACCOUNT_EMAIL
- name: GOOGLE_APPLICATION_CREDENTIALS
  value: $(Pipeline.Workspace)/.workload_identity.wlconfig

steps:
  - task: AzureCLI@2
    inputs:
      connectedServiceNameARM: $(Azure.WorkloadIdentity.Connection)
      addSpnToEnvironment: true
      scriptType: 'bash'
      scriptLocation: 'inlineScript'
      inlineScript: |
        echo $idToken > $(Pipeline.Workspace)/.workload_identity.jwt
        cat << EOF > $GOOGLE_APPLICATION_CREDENTIALS
        {
          "type": "external_account",
          "audience": "//iam.googleapis.com/projects/$(GoogleCloud.WorkloadIdentity.ProjectNumber)/locations/global/workloadIdentityPools/$(GoogleCloud.WorkloadIdentity.Pool)/providers/$(GoogleCloud.WorkloadIdentity.Provider)",
          "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
          "token_url": "https://sts.googleapis.com/v1/token",
          "credential_source": {
            "file": "$(Pipeline.Workspace)/.workload_identity.jwt"
          },
          "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/$(GoogleCloud.WorkloadIdentity.ServiceAccount):generateAccessToken"
        }
        EOF

Substitua os seguintes valores:

• CONNECTION: o nome da ligação ao serviço.
• PROJECT_NUMBER: o número do projeto que contém o Workload Identity Pool.
• POOL_ID: o ID do Workload Identity Pool.
• PROVIDER_ID: o ID do fornecedor do Workload Identity Pool.
• SERVICE_ACCOUNT_EMAIL: o endereço de email da conta de serviço, se usar a representação da conta de serviço. Se usar o acesso direto aos recursos, omita GoogleCloud.WorkloadIdentity.ServiceAccount e service_account_impersonation_url.

A configuração faz o seguinte:

1. Usa a tarefa AzureCLI para obter um token de ID para a ligação de serviço e disponibiliza-o numa variável denominada idToken.
2. Guarda o token de ID num ficheiro temporário denominado .workload_identity.jwt.
3. Cria um ficheiro de configuração de credenciais que indica às bibliotecas cliente para ler o token de ID de .workload_identity.jwt e usá-lo para se fazer passar por uma conta de serviço.
4. Define a variável de ambiente GOOGLE_APPLICATION_CREDENTIALS para apontar para o ficheiro de configuração das credenciais.

GitHub Actions

A ação google-github-actions/auth permite-lhe gerar automaticamente um ficheiro de configuração de credenciais durante a execução do fluxo de trabalho. As bibliotecas cliente e as ferramentas, como terraform podem, em seguida, usar este ficheiro de configuração de credenciais para obter automaticamente credenciais Google.

Edite o ficheiro YAML do GitHub Actions e adicione o seguinte:

• Permita que a tarefa obtenha um token de ID do GitHub adicionando a seguinte configuração:

  permissions:
    id-token: write
    contents: read
  

• Adicione um passo para criar um ficheiro de configuração de credenciais:

  - id: 'auth'
    name: 'Authenticate to Google Cloud'
    uses: 'google-github-actions/auth@v1'
    with:
      create_credentials_file: true
      workload_identity_provider: 'projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID'
      service_account: 'SERVICE_ACCOUNT_EMAIL'
  

Substitua o seguinte:

• PROJECT_NUMBER: o número do projeto do projeto que contém o Workload Identity Pool.
• POOL_ID: o ID do Workload Identity Pool.
• PROVIDER_ID: o ID do fornecedor do Workload Identity Pool.
• SERVICE_ACCOUNT_EMAIL: o endereço de email da conta de serviço, se usar a simulação de conta de serviço. Se usar o acesso direto a recursos, omita service_account.

O exemplo seguinte configura a ação do GitHub:

jobs:
  build:
    # Allow the job to fetch a GitHub ID token
    permissions:
      id-token: write
      contents: read

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - id: 'auth'
        name: 'Authenticate to Google Cloud'
        uses: 'google-github-actions/auth@v1'
        with:
          create_credentials_file: true
          workload_identity_provider: 'projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID'
          service_account: 'SERVICE_ACCOUNT_EMAIL'

Para mais detalhes sobre a utilização da ação google-github-actions/auth, consulte o artigo Configurar a Federação de identidades de carga de trabalho.

GitLab SaaS

Edite o ficheiro .gitlab-ci.yml e adicione o seguinte à configuração da tarefa:

job:
  variables:
    WORKLOAD_IDENTITY_PROJECT_NUMBER: PROJECT_NUMBER
    WORKLOAD_IDENTITY_POOL: POOL_ID
    WORKLOAD_IDENTITY_PROVIDER: PROVIDER_ID
    SERVICE_ACCOUNT: SERVICE_ACCOUNT_EMAIL
    GOOGLE_APPLICATION_CREDENTIALS: $CI_BUILDS_DIR/.workload_identity.wlconfig

  id_tokens:
    WORKLOAD_IDENTITY_TOKEN:
      aud: https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID

  script:
    - |-
      echo $WORKLOAD_IDENTITY_TOKEN > $CI_BUILDS_DIR/.workload_identity.jwt
      cat << EOF > $GOOGLE_APPLICATION_CREDENTIALS
      {
        "type": "external_account",
        "audience": "//iam.googleapis.com/projects/$WORKLOAD_IDENTITY_PROJECT_NUMBER/locations/global/workloadIdentityPools/$WORKLOAD_IDENTITY_POOL/providers/$WORKLOAD_IDENTITY_PROVIDER",
        "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
        "token_url": "https://sts.googleapis.com/v1/token",
        "credential_source": {
          "file": "$CI_BUILDS_DIR/.workload_identity.jwt"
        },
        "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/$SERVICE_ACCOUNT:generateAccessToken"
      }
      EOF

Substitua os seguintes valores:

• PROJECT_NUMBER: o número do projeto do projeto que contém o Workload Identity Pool.
• POOL_ID: o ID do Workload Identity Pool.
• PROVIDER_ID: o ID do fornecedor do Workload Identity Pool.
• SERVICE_ACCOUNT_EMAIL: o endereço de email da conta de serviço, se usar a representação da conta de serviço. Se usar o acesso direto aos recursos, omita SERVICE_ACCOUNT e service_account_impersonation_url.

A configuração faz o seguinte:

1. Indica ao GitLab que emita um token de ID e disponibiliza-o na variável de ambiente denominada WORKLOAD_IDENTITY_TOKEN. O token de ID usa o seu fornecedor do Workload Identity Pool como público-alvo.
2. Guarda o token de ID num ficheiro temporário denominado .workload_identity.jwt.
3. Cria um ficheiro de configuração de credenciais que indica às bibliotecas cliente para ler o token de ID de .workload_identity.jwt e usá-lo para roubar a identidade de uma conta de serviço.
4. Define a variável de ambiente GOOGLE_APPLICATION_CREDENTIALS para apontar para o ficheiro de configuração das credenciais.

Terraform Cloud

Configure o seu espaço de trabalho do Terraform Cloud para que use a Workload Identity Federation para autenticar-se no Google Cloud usando a representação da conta de serviço:

1. No Terraform Cloud, abra o seu espaço de trabalho e aceda a Variáveis.

2. Adicione as seguintes variáveis:

   Categoria da variável	Chave	Valor
   Variável de ambiente	TFC_GCP_PROVIDER_AUTH	true
   Variável de ambiente	TFC_GCP_RUN_SERVICE_ACCOUNT_EMAIL	O endereço de email da conta de serviço, se usar a simulação de conta de serviço, por exemplo, [e-mail]. Omita esta variável de ambiente se usar o acesso direto aos recursos.
   Variável de ambiente	TFC_GCP_PROJECT_NUMBER	O número do projeto que contém o Workload Identity Pool
   Variável de ambiente	TFC_GCP_WORKLOAD_POOL_ID	O ID do Workload Identity Pool
   Variável de ambiente	TFC_GCP_WORKLOAD_PROVIDER_ID	O ID do fornecedor do Workload Identity Pool

   Opcionalmente, se usar a representação da conta de serviço, pode adicionar variáveis de ambiente adicionais para permitir que o Terraform Cloud use contas de serviço diferentes para as fases plan e apply. Para mais informações sobre a utilização de variáveis de ambiente em configurações do Terraform, consulte o artigo Variáveis de ambiente opcionais.

3. Na lista de variáveis, verifique se a Categoria está definida como env para as cinco variáveis que adicionou no passo anterior.

4. Verifique se a sua configuração do Terraform usa a versão 4.48.0 ou mais recente do fornecedor e atualize-a, se necessário, da seguinte forma: Google Cloud

   terraform {
     required_providers {
       google = {
         source  = "hashicorp/google"
         version = "~> 4.48.0"
       }
     }
   }
   

5. Envie as alterações para o repositório de código-fonte.

O que se segue?

• Leia mais sobre a federação de identidades da carga de trabalho.
• Saiba mais acerca das práticas recomendadas para usar a Workload Identity Federation em pipelines de implementação.
• Veja como pode gerir Workload Identity Pools e fornecedores.

Envie comentários