Configura la federazione delle identità per i carichi di lavoro con pipeline di deployment

Questa guida descrive come utilizzare la federazione delle identità per i carichi di lavoro per consentire l'autenticazione delle pipeline di deployment in Google Cloud.

A seconda del sistema CI/CD in uso, le pipeline di deployment potrebbero avere accesso a credenziali ambientali specifiche dell'ambiente. Ad esempio:

Le pipeline Azure DevOps possono utilizzare una connessione al servizio di federazione delle identità per i carichi di lavoro Microsoft Entra per ottenere un token ID che identifichi in modo univoco il progetto Azure DevOps.
I flussi di lavoro di GitHub Actions possono ottenere un token OIDC GitHub che identifica in modo univoco il flusso di lavoro e il relativo repository.
GitLab SaaS consente ai job CI/CD di accedere a un token ID che identifica in modo univoco il job e il relativo progetto, ambiente e repository.
Terraform Cloud può fornire un token OIDC alla tua configurazione Terraform che identifica in modo univoco l'area di lavoro e l'ambiente.

Puoi configurare le pipeline di deployment in modo da utilizzare queste credenziali per l'autenticazione in Google Cloud mediante la federazione delle identità per i carichi di lavoro. Questo approccio elimina il carico di manutenzione e sicurezza associato alle chiavi degli account di servizio.

Prima di iniziare

Configura l'autenticazione

Seleziona la scheda relativa a come prevedi di utilizzare gli esempi in questa pagina:

Console

Quando utilizzi la console Google Cloud per accedere ai servizi e alle API di Google Cloud, non devi configurare l'autenticazione.

gcloud

In questa pagina puoi utilizzare gli esempi di gcloud CLI da uno dei seguenti ambienti di sviluppo:

Cloud Shell: per utilizzare un terminale online con gcloud CLI già configurato, attiva Cloud Shell.

In fondo a questa pagina viene avviata una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. L'inizializzazione della sessione può richiedere alcuni secondi.
shell locale: per utilizzare gcloud CLI in un ambiente di sviluppo locale, installa e initialize gcloud CLI.

Python

Per utilizzare gli esempi Python in questa pagina da un ambiente di sviluppo locale, installa e inizializza gcloud CLI, quindi configura Credenziali predefinite dell'applicazione con le tue credenziali utente.

Installa Google Cloud CLI.
Per initialize gcloud CLI, esegui questo comando:
```
gcloud init
```

Crea credenziali di autenticazione locali per il tuo Account Google:
```
gcloud auth application-default login
```

Per saperne di più, consulta Configurare l'autenticazione per un ambiente di sviluppo locale nella documentazione sull'autenticazione di Google Cloud.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per configurare la federazione delle identità per i carichi di lavoro, chiedi all'amministratore di concederti il ruolo IAM Amministratore pool di identità per carichi di lavoro (roles/iam.workloadIdentityPoolAdmin) sul progetto. Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso.

Potresti anche essere in grado di ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

In alternativa, il ruolo di base Proprietario IAM (roles/owner) include anche le autorizzazioni per configurare la federazione delle identità. Non devi concedere ruoli di base in un ambiente di produzione, ma puoi concederli in un ambiente di sviluppo o test.

Prepara l'IdP esterno

DevOps di Azure

Per consentire a una pipeline Azure DevOps di eseguire l'autenticazione in Google Cloud, devi prima configurare una connessione a un servizio per Azure Resource Manager. Questa connessione consente alla pipeline di ottenere un token ID, che può poi scambiare con le credenziali Google Cloud.

Per creare una connessione al servizio per Azure Resource Manager:

In Azure DevOps, apri il tuo progetto e vai a Impostazioni progetto.
Vai a Pipeline > Connessioni ai servizi.
Fai clic su Crea connessione al servizio.
Seleziona Azure Resource Manager.
Tocca Avanti.
Seleziona Federazione delle identità per i carichi di lavoro (automatica)
Tocca Avanti.
Configura le seguenti impostazioni:
- Livello di ambito: seleziona un abbonamento.
  
  Devi selezionare un abbonamento anche se non prevedi di utilizzare la connessione al servizio per accedere alle risorse Azure.
- Nome connessione al servizio: inserisci un nome, ad esempio google-cloud.
Fai clic su Salva.

In un passaggio successivo, avrai bisogno dell'emittente e dell'identificatore del soggetto della connessione al servizio. Per cercare questi dettagli, segui questi passaggi:

Fai clic sulla connessione al servizio appena creata.
Fai clic su Gestisci entità servizio.
Vai a Certificati e segreti > Credenziali federate.
Fai clic sulla credenziale federata.
Nella pagina Modifica una credenziale, trova i seguenti identificatori:
- Issuer (Emittente): identifica in modo univoco la tua organizzazione Azure DevOps
- Identificatore soggetto: identifica in modo univoco la connessione al servizio

DevOps di Azure concede automaticamente l'accesso all'abbonamento selezionato come ambito all'entità di servizio associata alla nuova connessione al servizio. Poiché non prevedi di utilizzare la connessione al servizio per accedere alle risorse Azure, puoi revocare questo accesso seguendo questi passaggi:

Nel portale Azure, apri la sottoscrizione che hai selezionato come ambito.
Vai a Controllo dell'accesso (IAM) > Assegnazioni dei ruoli.
Trova l'assegnazione del ruolo per la connessione al servizio e rimuovila.

Azioni GitHub

Non è necessario apportare modifiche alla configurazione del tuo account GitHub.

Dopo aver configure un pool di identità per i carichi di lavoro in modo che il repository GitHub di identità sia attendibile, puoi consentire ai flussi di lavoro all'interno del repository di utilizzare il proprio token OIDC GitHub per ottenere credenziali Google Cloud di breve durata.

SaaS GitLab

Non è necessario apportare alcuna modifica alla configurazione nel tuo account GitLab.

Dopo aver configure un pool di identità per i carichi di lavoro in modo che il gruppo GitLab sia attendibile, puoi abilitare la federazione delle identità per i carichi di lavoro per singoli job CI/CD.

Terraform sul cloud

Non è necessario apportare modifiche alla configurazione nel tuo account Terraform Cloud.

Dopo aver configure un pool di identità per i carichi di lavoro in cui considerare attendibile Terraform Cloud, puoi abilitare la federazione delle identità per i carichi di lavoro per le singole aree di lavoro.

Configura la federazione delle identità per i carichi di lavoro

Devi eseguire questi passaggi per ogni organizzazione GitHub, gruppo GitLab o organizzazione Terraform Cloud.

Per avviare la configurazione della federazione delle identità per i carichi di lavoro:

Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.

Vai al selettore progetti

utilizzare un progetto dedicato per gestire provider e pool di identità per i carichi di lavoro

Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

Abilita le API IAM, Resource Manager, Service Account Credentials, and Security Token Service.

Abilita le API

Definisci una mappatura degli attributi

Le credenziali specifiche per l'ambiente della pipeline di deployment possono contenere più attributi e devi decidere quale attributo utilizzare come identificatore soggetto (google.subject) in Google Cloud.

Se vuoi, puoi mappare ulteriori attributi. Puoi quindi fare riferimento a questi attributi aggiuntivi quando concedi l'accesso alle risorse.

DevOps di Azure

Il token ID DevOps di Azure include un'attestazione sub che contiene l'identificatore del soggetto della connessione al servizio. L'identificatore del soggetto utilizza il seguente formato:

sc://ORGANIZATION/PROJECT/CONNECTION

Utilizza la seguente mappatura degli attributi per mappare questo identificatore a google.subject:

google.subject=assertion.sub

Azioni GitHub

Le mappature degli attributi possono utilizzare qualsiasi rivendicazione nel token OIDC delle azioni GitHub. Queste chiavi di attestazione dei token e i relativi valori sono controllati da GitHub. Come minimo, devi mappare google.subject a assertion.sub, che corrisponde all'oggetto del token OIDC delle azioni GitHub:

google.subject=assertion.sub

Il valore dell'oggetto del token OIDC delle azioni GitHub può variare a seconda dell'evento di origine. Altri attributi delle rivendicazioni possono includere:

repository: contiene il nome del proprietario e del repository, ad esempio "google/guava".
repository_id: contiene l'ID repository univoco, ad esempio "20300177".
repository_owner: contiene il proprietario, che può essere un nome utente o il nome di un'organizzazione GitHub, ad esempio "google".
repository_owner_id: contiene l'ID proprietario univoco, ad esempio "1342004".

L'elenco riportato sopra è un sottoinsieme delle possibili rivendicazioni. Per un elenco completo, consulta la documentazione di GitHub sulle rivendicazioni di esempio. Assicurati di mappare tutte le rivendicazioni che prevedi di utilizzare come condizioni degli attributi o come parte di una condizione principalSet futura.

SaaS GitLab

Le mappature degli attributi possono utilizzare le rivendicazioni incorporate nel token ID GitLab come attributi di origine, tra cui:

sub: il nome del progetto e il riferimento Git, ad esempio project_path:groupname/projectname:ref_type:branch:ref:main.
namespace_id: l'ID gruppo univoco.
project_id: l'ID progetto univoco.
user_id: l'ID utente univoco.
environment: l'ambiente a cui si applica il job.
ref_path: il riferimento Git, ad esempio refs/heads/main.

Il seguente mapping degli attributi imposta google.subject sull'attestazione sub dal token ID GitLab. Poiché l'attestazione sub contiene sia il nome del progetto sia il riferimento Git, questa mappatura consente di controllare l'accesso per repository e ramo:

google.subject=assertion.sub

Il controllo dell'accesso per repository e ramo può essere utile se determinati rami (ad esempio main) hanno bisogno di un accesso diverso alle risorse rispetto ad altri rami (ad esempio, rami di funzionalità).

In alcuni casi, potrebbe essere sufficiente differenziare l'accesso solo per proiettore o gruppo. Il seguente mapping include quindi due attributi aggiuntivi che contengono i GitLab project_id e namespace_id:

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

Terraform sul cloud

Le mappature degli attributi possono utilizzare le attestazioni incorporate nel token Terraform Cloud OIDC, tra cui:

terraform_organization_id: contiene l'ID univoco dell'organizzazione, ad esempio org-xxxxxxxxxxxxxxxx.
terraform_workspace_id: contiene l'ID univoco dello spazio di lavoro, ad esempio ws-xxxxxxxxxxxxxxxx.
terraform_workspace_name: contiene il nome visualizzato dello spazio di lavoro.
sub: contiene il nome visualizzato dell'organizzazione, dell'area di lavoro e della fase, ad esempio organization:example-org:workspace:example-workspace:run_phase:apply.

Il seguente mapping degli attributi imposta google.subject sulla richiesta terraform_workspace_id dal token OIDC Cloud Terraform:

google.subject=assertion.terraform_workspace_id

Questo mapping consente di controllare l'accesso alle risorse Google Cloud in base all'area di lavoro.

Definisci una condizione dell'attributo

Le condizioni degli attributi sono espressioni CEL in grado di controllare gli attributi delle asserzioni e gli attributi di destinazione. Se la condizione dell'attributo restituisce true per una determinata credenziale, la credenziale viene accettata. In caso contrario, la credenziale viene rifiutata. Devi avere una mappatura degli attributi per tutti i campi di condizione degli attributi.

DevOps di Azure

Facoltativamente, utilizza una condizione dell'attributo per limitare l'accesso a determinate connessioni a servizi. Ad esempio, la seguente condizione limita l'accesso alle connessioni in un determinato progetto DevOps di Azure:

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

Sostituisci quanto segue:

ORGANIZATION: il nome della tua organizzazione Azure DevOps.
PROJECT: il nome del tuo progetto Azure DevOps.

Azioni GitHub

Utilizza la seguente condizione degli attributi per limitare l'accesso ai token emessi dalla tua organizzazione GitHub:

assertion.repository_owner=='ORGANIZATION'

Sostituisci ORGANIZATION con il nome della tua organizzazione GitHub.

Facoltativamente, estendi la condizione dell'attributo per limitare l'accesso a un sottoinsieme di flussi di lavoro o rami. Ad esempio, la seguente condizione limita l'accesso ai flussi di lavoro che utilizzano il ramo Git main:

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

SaaS GitLab

Utilizza la seguente condizione degli attributi per limitare l'accesso ai token emessi dal tuo gruppo GitHub

assertion.namespace_id=='GROUP_ID'

Sostituisci GROUP_ID con l'ID gruppo visualizzato nella home page del gruppo GitLab.

Facoltativamente, estendi la condizione dell'attributo per limitare l'accesso a un sottoinsieme di progetti, rami o ambienti. Ad esempio, la seguente condizione limita l'accesso ai job che utilizzano l'ambiente production:

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

Terraform sul cloud

Utilizza la seguente condizione degli attributi per limitare l'accesso ai token emessi dalla tua organizzazione Terraform:

assertion.terraform_organization_id=='ORGANIZATION_ID'

Sostituisci ORGANIZATION_ID con l'ID univoco della tua organizzazione, ad esempio org-xxxxxxxxxxxxxxxx. Facoltativamente, estendi la condizione dell'attributo per limitare l'accesso a un sottoinsieme di flussi di lavoro o rami. Ad esempio, la seguente condizione degli attributi limita l'accesso a un'area di lavoro specifica:

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

Crea il pool di identità per i carichi di lavoro e il provider

Hai raccolto tutte le informazioni necessarie per creare un provider e un pool di identità per i carichi di lavoro:

Console

Nella console Google Cloud, vai alla pagina Nuovo provider e pool di carichi di lavoro.

Vai a Nuovo provider e pool di carichi di lavoro
In Crea un pool di identità, inserisci quanto segue:
- Nome: il nome del pool. Il nome viene utilizzato anche come ID pool. Non potrai modificare l'ID pool in un secondo momento.
- Descrizione: testo che descrive lo scopo del pool.
Fai clic su Continua.
Configura le impostazioni del provider:
DevOps di Azure
- Seleziona un provider: OpenID Connect (OIDC).
- Nome provider: il nome del progetto Azure DevOps o un nome personalizzato.
- Provider ID: nome del progetto Azure DevOps o un ID personalizzato. Non potrai modificare l'ID provider in un secondo momento.
- Issuer URL (URL emittente): l'emittente della connessione al servizio che hai cercato in precedenza.
- Segmenti di pubblico: seleziona Segmenti di pubblico consentiti e incolla il seguente valore.
```
api://AzureADTokenExchange
```
Azioni GitHub
- Seleziona un provider: OpenID Connect (OIDC).
- Nome provider: il nome del provider.
- ID provider: ID del provider. Non potrai modificare l'ID provider in un secondo momento.
- URL emittente: https://token.actions.githubusercontent.com/
- Segmenti di pubblico: Pubblico predefinito
SaaS GitLab
- Seleziona un provider: OpenID Connect (OIDC).
- Nome provider: il nome del provider.
- ID provider: ID del provider. Non potrai modificare l'ID provider in un secondo momento.
- URL emittente: https://gitlab.com
- Segmenti di pubblico: Pubblico predefinito
Terraform sul cloud
- Seleziona un provider: OpenID Connect (OIDC).
- Nome provider: il nome del provider.
- ID provider: ID del provider. Non potrai modificare l'ID provider in un secondo momento.
- URL emittente: https://app.terraform.io
- Segmenti di pubblico: Pubblico predefinito
Fai clic su Continua.
In Configura gli attributi del provider, aggiungi le mappature degli attributi identificate in precedenza.
In Condizioni degli attributi, inserisci la condizione dell'attributo identificata in precedenza.
Fai clic su Salva per creare il provider e il pool di identità per i carichi di lavoro.

gcloud

Crea un nuovo pool di identità per i carichi di lavoro:
```
gcloud iam workload-identity-pools create POOL_ID \
    --location="global" \
    --description="DESCRIPTION" \
    --display-name="DISPLAY_NAME"
```
Sostituisci i seguenti valori:
- POOL_ID: l'ID univoco del pool
- DISPLAY_NAME: il nome del pool
- DESCRIPTION: la descrizione del pool. Questa descrizione viene visualizzata quando si concede l'accesso alle identità del pool
Aggiungi un provider di pool di identità per i carichi di lavoro:
DevOps di Azure
```
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="ISSUER" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
Sostituisci i seguenti valori:
- PROVIDER_ID: il nome del progetto Azure DevOps o un ID personalizzato per il provider.
- POOL_ID: l'ID del pool
- ISSUER: l'emittente della connessione al servizio che hai cercato in precedenza.
- MAPPINGS: un elenco separato da virgole di mappature degli attributi che hai identificato in precedenza
- CONDITIONS: la condizione dell'attributo identificata in precedenza
Azioni GitHub
```
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="https://token.actions.githubusercontent.com/" \
    --allowed-audiences="api://AzureADTokenExchange" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
Sostituisci i seguenti valori:
- PROVIDER_ID: l'ID univoco del provider
- POOL_ID: l'ID del pool
- MAPPINGS: un elenco separato da virgole di mappature degli attributi che hai identificato in precedenza
- CONDITIONS: la condizione dell'attributo identificata in precedenza
SaaS GitLab
```
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"
```
Sostituisci i seguenti valori:
- PROVIDER_ID: l'ID univoco del provider
- POOL_ID: l'ID del pool
- MAPPINGS: un elenco separato da virgole di mappature degli attributi che hai identificato in precedenza
- CONDITIONS: la condizione dell'attributo identificata in precedenza
Terraform sul 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"
```
Sostituisci i seguenti valori:
- PROVIDER_ID: l'ID univoco del provider.
- POOL_ID: l'ID del pool.
- MAPPINGS: un elenco separato da virgole di mappature degli attributi che hai identificato in precedenza.
- CONDITIONS: la condizione dell'attributo che hai identificato in precedenza.

Aggiorna la condizione degli attributi su un provider di identità per i carichi di lavoro

Questa sezione descrive come aggiornare la condizione degli attributi su un provider di pool di identità per carichi di lavoro esistente per limitare l'accesso ai token emessi dalla tua organizzazione GitHub, dal gruppo GitLab o dall'organizzazione Terraform Cloud.

Per trovare la condizione degli attributi consigliata per la tua pipeline, consulta Definire una condizione dell'attributo.

Console

Nella console Google Cloud, vai alla pagina Pool di identità carichi di lavoro.

Vai ai pool Workload Identity
Individua il pool di identità per i carichi di lavoro che contiene il provider, quindi fai clic sull'icona Espandi nodo per il pool.
Trova il provider di pool di identità per i carichi di lavoro che vuoi modificare e fai clic su Modifica.
In Condizioni degli attributi, inserisci la condizione dell'attributo identificata in precedenza.
Per aggiornare il pool di identità per i carichi di lavoro e il provider, fai clic su Salva.

gcloud

Per aggiornare il provider del pool di identità per i carichi di lavoro, esegui questo comando:

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

Sostituisci i seguenti valori:

PROVIDER_ID: l'ID univoco del provider
POOL_ID: l'ID del pool
CONDITIONS: la condizione dell'attributo che hai identificato in precedenza

Autentica una pipeline di deployment

Devi eseguire questi passaggi per ogni flusso di lavoro delle azioni GitHub o per ogni area di lavoro Terraform Cloud.

Crea un account di servizio per la pipeline di deployment

Abilita le API IAM, Security Token Service, and Service Account Credentials.
Abilita le API
Crea un account di servizio che rappresenti il carico di lavoro. Ti consigliamo di utilizzare un account di servizio dedicato per ogni pipeline di deployment.

L'account di servizio non deve necessariamente trovarsi nello stesso progetto del pool di identità dei carichi di lavoro.
Concedi all'account di servizio l'accesso alle risorse a cui vuoi che accedano le identità esterne.

Consenti alla pipeline di deployment di impersonare l'account di servizio

Per consentire a identità esterne di impersonare un account di servizio, concedi loro il ruolo Utente Workload Identity (roles/iam.workloadIdentityUser) per l'account di servizio. Puoi concedere il ruolo a un'identità esterna specifica o a più identità esterne:

Per un'identità esterna specifica, scrivi una condizione dell'attributo che controlli l'attributo google.subject.
Per un gruppo di identità esterne, scrivi una condizione dell'attributo che controlli l'attributo google.groups o un attributo personalizzato attribute.NAME.

Console

Per consentire alle identità esterne di impersonare un account di servizio utilizzando la console Google Cloud:

Nella console Google Cloud, vai alla pagina Pool di identità carichi di lavoro.

Vai ai pool Workload Identity
Individua e seleziona il pool Workload Identity da aggiornare.
Per concedere l'accesso al pool di identità per i carichi di lavoro selezionato, fai clic su Concedi l'accesso.
Nell'elenco Account di servizio, seleziona l'account di servizio per le identità esterne da impersonare.
Per scegliere quali identità nel pool possono impersonare l'account di servizio, esegui una delle seguenti azioni:
- Per consentire solo a identità specifiche del pool di identità per i carichi di lavoro di assumere l'identità dell'account di servizio, seleziona Solo le identità che corrispondono al filtro.
  
  Nell'elenco Nome attributo, seleziona l'attributo in base al quale applicare il filtro.
  
  Nel campo Valore attributo, inserisci il valore previsto dell'attributo; ad esempio, se utilizzi una mappatura degli attributi google.subject=assertion.sub, imposta Nome attributo su subject e Valore attributo sul valore dell'attestazione sub nei token emessi dal tuo provider di identità esterno.
Per salvare la configurazione, fai clic su Salva e poi su Ignora.

gcloud

Per consentire alle identità esterne di impersonare un account di servizio utilizzando gcloud CLI, segui questi passaggi:

Per ottenere il numero del tuo progetto attuale, esegui questo comando:

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

Per concedere il ruolo Utente Workload Identity (roles/iam.workloadIdentityUser) alle identità esterne che soddisfano determinati criteri:

Per soggetto

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"

Per gruppo

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"

Per attributo

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"

Sostituisci quanto segue:

SERVICE_ACCOUNT_EMAIL: l'indirizzo email dell'account di servizio
PROJECT_NUMBER: il numero di progetto del progetto che contiene il pool di identità per i carichi di lavoro
POOL_ID: l'ID pool del pool di identità per i carichi di lavoro
SUBJECT: il valore previsto per l'attributo che hai mappato a google.subject
GROUP: il valore previsto per l'attributo che hai mappato a google.groups
ATTRIBUTE_NAME: il nome di un attributo personalizzato nella mappatura degli attributi

Configura la pipeline di deployment

Ora è tutto pronto per utilizzare la federazione delle identità per i carichi di lavoro nella pipeline di deployment.

DevOps di Azure

Modifica il file azure-pipelines.yml e aggiungi quanto segue alla configurazione del job:

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

Sostituisci i seguenti valori:

CONNECTION: il nome della connessione al servizio
PROJECT_NUMBER: il numero del progetto che contiene il pool di identità per i carichi di lavoro
POOL_ID: l'ID del pool di identità per i carichi di lavoro
PROVIDER_ID: l'ID del provider del pool di identità per i carichi di lavoro
SERVICE_ACCOUNT_EMAIL: l'indirizzo email dell'account di servizio

La configurazione esegue quanto segue:

Utilizza l'attività AzureCLI per ottenere un token ID per la connessione al servizio e lo rende disponibile in una variabile denominata idToken.
Salva il token ID in un file temporaneo denominato .workload_identity.jwt.
Crea un file di configurazione delle credenziali che indica alle librerie client di leggere il token ID da .workload_identity.jwt e lo utilizza per impersonare un account di servizio.
Imposta la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS in modo che punti al file di configurazione delle credenziali.

Azioni GitHub

L'azione google-github-actions/auth consente di generare automaticamente un file di configurazione delle credenziali durante l'esecuzione del flusso di lavoro. Le librerie client e gli strumenti come terraform possono quindi utilizzare questo file di configurazione delle credenziali per ottenere automaticamente le credenziali di Google.

Modifica il file YAML delle azioni di GitHub e aggiungi quanto segue:

Consenti al job di recuperare un token ID GitHub aggiungendo la seguente configurazione:
```
permissions:
  id-token: write
  contents: read
```

Aggiungi un passaggio per creare un file di configurazione delle credenziali:

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

Sostituisci i seguenti valori:

PROJECT_NUMBER: il numero del progetto che contiene il pool di identità per i carichi di lavoro
POOL_ID: l'ID del pool di identità per i carichi di lavoro
PROVIDER_ID: l'ID del provider del pool di identità per i carichi di lavoro
SERVICE_ACCOUNT_EMAIL: l'indirizzo email dell'account di servizio

Esempio:

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'

Per ulteriori dettagli sull'utilizzo dell'azione google-github-actions/auth, consulta Configurazione della federazione di Workload Identity.

SaaS GitLab

Modifica il file .gitlab-ci.yml e aggiungi quanto segue alla configurazione del job:

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

Sostituisci i seguenti valori:

PROJECT_NUMBER: il numero del progetto che contiene il pool di identità per i carichi di lavoro
POOL_ID: l'ID del pool di identità per i carichi di lavoro
PROVIDER_ID: l'ID del provider del pool di identità per i carichi di lavoro
SERVICE_ACCOUNT_EMAIL: l'indirizzo email dell'account di servizio

La configurazione esegue quanto segue:

Chiedi a GitLab di emettere un token ID e di renderlo disponibile nella variabile di ambiente denominata WORKLOAD_IDENTITY_TOKEN. Il token ID utilizza il provider del pool di identità per i carichi di lavoro come pubblico.
Salva il token ID in un file temporaneo denominato .workload_identity.jwt.
Crea un file di configurazione delle credenziali che indica alle librerie client di leggere il token ID da .workload_identity.jwt e utilizzarlo per impersonare un account di servizio.
Imposta la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS in modo che punti al file di configurazione delle credenziali.

Terraform sul cloud

Configura l'area di lavoro Terraform Cloud in modo che utilizzi la federazione delle identità per i carichi di lavoro per l'autenticazione in Google Cloud:

In Terraform Cloud, apri l'area di lavoro e vai a Variabili.

Aggiungi le seguenti variabili:

Categoria variabile	Chiave	Valore
Variabile di ambiente	`TFC_GCP_PROVIDER_AUTH`	`true`
Variabile di ambiente	`TFC_GCP_RUN_SERVICE_ACCOUNT_EMAIL`	L'indirizzo email dell'account di servizio, ad esempio `terraform@my-project-123.iam.gserviceaccount.com`
Variabile di ambiente	`TFC_GCP_PROJECT_NUMBER`	Il numero del progetto che contiene il pool di identità per i carichi di lavoro
Variabile di ambiente	`TFC_GCP_WORKLOAD_POOL_ID`	L'ID del pool di identità per i carichi di lavoro
Variabile di ambiente	`TFC_GCP_WORKLOAD_PROVIDER_ID`	L'ID del provider del pool di identità per i carichi di lavoro

Se vuoi, puoi aggiungere altre variabili di ambiente per consentire a Terrform Cloud di utilizzare account di servizio diversi per le fasi plan e apply. Per ulteriori informazioni, consulta Variabili di ambiente facoltative.

Nell'elenco delle variabili, verifica che Categoria sia impostata su env per le cinque variabili aggiunte nel passaggio precedente.
Verifica che la tua configurazione Terraform utilizzi la versione 4.48.0 o successiva del provider Google Cloud e, se necessario, aggiornala come segue:
```
terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 4.48.0"
    }
  }
}
```
Invia le modifiche al repository di codice sorgente.

Passaggi successivi

Scopri di più sulla federazione delle identità per i carichi di lavoro.
Scopri le best practice per l'utilizzo della federazione delle identità per i carichi di lavoro nelle pipeline di deployment.
Scopri come gestire pool di identità per i carichi di lavoro e provider.