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

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

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

  • Le pipeline Azure DevOps possono utilizzare una connessione di servizio di federazione delle identità per i workload di Microsoft Entra per ottenere un token ID che identifica in modo univoco il progetto Azure DevOps.
  • I flussi di lavoro di GitHub Actions possono ottenere un token OIDC di 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 lo spazio di lavoro e l'ambiente.

Puoi configurare le pipeline di deployment in modo che utilizzino queste credenziali per l'autenticazione a Google Cloud utilizzando la federazione delle identità per i carichi di lavoro. Questo approccio elimina l'onere di manutenzione e sicurezza associato alle chiavi del service account.

Prima di iniziare

Configura l'autenticazione

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

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

    1. Install the Google Cloud CLI.

    2. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

    3. To initialize the gcloud CLI, run the following command: 

      gcloud init

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

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

    Ruoli obbligatori

    Per ottenere le autorizzazioni necessarie per configurare la federazione delle identità dei carichi di lavoro, chiedi all'amministratore di concederti il ruolo IAM Workload Identity Pool Admin (roles/iam.workloadIdentityPoolAdmin) nel progetto. Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

    Potresti anche riuscire a 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 di test.

    Prepara il tuo IdP esterno

    Azure DevOps

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

    Per creare una connessione di servizio per Azure Resource Manager:

    1. In Azure DevOps, apri il progetto e vai a Impostazioni progetto.
    2. Vai a Pipeline > Connessioni di servizio.
    3. Fai clic su Crea connessione di servizio.
    4. Seleziona Azure Resource Manager.
    5. Fai clic su Avanti.

    6. Configura le seguenti impostazioni:

      • Tipo di identità: Registrazione di app (automatica)
      • Credenziale: federazione delle identità dei carichi di lavoro

      • Livello di ambito: Abbonamento.

        Devi selezionare un abbonamento anche se non prevedi di utilizzare la connessione di servizio per accedere alle risorse Azure.

      • Nome connessione di servizio: inserisci un nome, ad esempio google-cloud.

    7. Fai clic su Salva.

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

    1. Fai clic sulla connessione al servizio che hai appena creato.
    2. Fai clic su Gestisci registrazione app.
    3. Seleziona Gestisci > Certificato e segreti > Credenziali federate.
    4. Fai clic sulla credenziale federata.

    5. Nella pagina Modifica una credenziale, trova i seguenti identificatori:

      • Emittente: identifica in modo univoco la tua organizzazione Azure DevOps
      • Identificatore del soggetto: identifica in modo univoco la connessione del servizio

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

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

    GitHub Actions

    Non è necessario apportare modifiche alla configurazione dell'account GitHub.

    Dopo aver configurato un pool di identità del workload in modo che consideri attendibile il tuo repository GitHub, puoi consentire ai workflow in quel repository di utilizzare il token GitHub OIDC per ottenere credenziali Google Cloud di breve durata.

    GitLab SaaS

    Non è necessario apportare modifiche alla configurazione dell'account GitLab.

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

    Terraform Cloud

    Non è necessario apportare modifiche alla configurazione nell'account Terraform Cloud.

    Dopo aver configurato un pool di identità per i carichi di lavoro in modo che consideri attendibile Terraform Cloud, puoi abilitare la federazione delle identità per i workload per i singoli workspace.

    Configura la federazione delle identità per i workload

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

    Per iniziare a configurare la federazione delle identità per i workload:

    1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

      Go to project selector

      2. È consigliabile utilizzare un progetto dedicato per gestire i provider e i pool di identità del workload.

    2. Make sure that billing is enabled for your Google Cloud project.

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

      Enable the APIs

    Definisci una mappatura degli attributi

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

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

    Azure DevOps

    Il token ID Azure DevOps include un claim 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

    GitHub Actions

    Le mappature degli attributi possono utilizzare qualsiasi rivendicazione nel token OIDC di GitHub Actions. Queste chiavi di rivendicazione del token e i relativi valori sono controllati da GitHub. Come minimo, devi mappare google.subject a assertion.sub, che corrisponde al soggetto del token OIDC di GitHub Actions:

    google.subject=assertion.sub

    Il valore del soggetto del token OIDC di GitHub Actions può variare a seconda dell'evento di origine. Altri attributi della rivendicazione possono includere:

    • repository: contiene il nome del proprietario e del repository, ad esempio "google/guava".

    • repository_id: contiene l'ID univoco del repository, 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".

    Questo elenco è 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 intendi utilizzare come condizioni degli attributi o come parte di una futura condizione principalSet.

    GitLab SaaS

    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 ti 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) richiedono un accesso alle risorse diverso rispetto ad altri rami (ad esempio, i rami delle funzionalità).

    In alcuni casi, potrebbe essere sufficiente differenziare l'accesso solo per progetto o gruppo. La seguente mappatura include quindi due attributi aggiuntivi che contengono project_id e namespace_id di GitLab:

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

    Terraform Cloud

    Le mappature degli attributi possono utilizzare le rivendicazioni incorporate nel token OIDC di Terraform Cloud, tra cui le seguenti

    • 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, dello spazio di lavoro e della fase, ad esempio organization:example-org:workspace:example-workspace:run_phase:apply.

    Il seguente mapping degli attributi imposta google.subject sull'attestazione terraform_workspace_id dal token OIDC di Terraform Cloud:

    google.subject=assertion.terraform_workspace_id

    Questa mappatura ti consente di controllare l'accesso alle risorse Google Cloud per spazio di lavoro.

    Definisci una condizione dell'attributo

    Le condizioni degli attributi sono espressioni CEL che possono controllare gli attributi dell'asserzione 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 delle condizioni degli attributi.

    Azure DevOps

    (Facoltativo) Utilizza una condizione dell'attributo per limitare l'accesso a determinate connessioni di servizio. Ad esempio, la seguente condizione limita l'accesso alle connessioni in un determinato progetto Azure DevOps:

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

    Sostituisci quanto segue:

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

    GitHub Actions

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

    assertion.repository_owner=='ORGANIZATION'

    Sostituisci ORGANIZATION con il nome della tua organizzazione GitHub.

    (Facoltativo) 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 workflow che utilizzano il ramo Git main:

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

    GitLab SaaS

    Utilizza la seguente condizione dell'attributo per limitare l'accesso ai token emessi dal tuo gruppo GitLab 

    assertion.namespace_id=='GROUP_ID'

    Sostituisci GROUP_ID con l'ID gruppo visualizzato nella home page del tuo 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 Cloud

    Utilizza la seguente condizione dell'attributo per limitare l'accesso ai token emessi dalla tua organizzazione Terraform Cloud:

    assertion.terraform_organization_id=='ORGANIZATION_ID'

    Sostituisci ORGANIZATION_ID con l'ID univoco della tua organizzazione, ad esempio org-xxxxxxxxxxxxxxxx. (Facoltativo) Estendi la condizione dell'attributo per limitare l'accesso a un sottoinsieme di flussi di lavoro o rami. Ad esempio, la seguente condizione dell'attributo limita l'accesso a uno spazio di lavoro specifico:

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

    Crea il fornitore e il pool di identità del workload

    Ora hai raccolto tutte le informazioni necessarie per creare un fornitore e un pool di identità del workload:

    Console

    1. Nella console Google Cloud , vai alla pagina Nuovo provider e pool di workload.

      Vai a Nuovo provider e pool di workload

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

    3. Fai clic su Continua.

    4. Configura le impostazioni del fornitore:

      Azure DevOps

      • Seleziona un provider: OpenID Connect (OIDC).
      • Nome del provider: il nome del progetto Azure DevOps o un nome personalizzato.
      • ID provider: il nome del progetto Azure DevOps o un ID personalizzato. Non potrai modificare l'ID fornitore in un secondo momento.
      • URL emittente: l'emittente della connessione di servizio che hai cercato in precedenza.

      • Segmenti di pubblico: seleziona Segmenti di pubblico consentiti e incolla il seguente valore

        api://AzureADTokenExchange

      GitHub Actions

      • Seleziona un provider: OpenID Connect (OIDC).
      • Nome provider: nome del provider.
      • ID fornitore: ID del fornitore. Non potrai modificare l'ID fornitore in un secondo momento.
      • URL emittente: https://token.actions.githubusercontent.com/
      • Segmenti di pubblico: Segmento di pubblico predefinito

      GitLab SaaS

      • Seleziona un provider: OpenID Connect (OIDC).
      • Nome provider: nome del provider.
      • ID fornitore: ID del fornitore. Non potrai modificare l'ID fornitore in un secondo momento.
      • URL emittente: https://gitlab.com
      • Segmenti di pubblico: Segmento di pubblico predefinito

      Terraform Cloud

      • Seleziona un provider: OpenID Connect (OIDC).
      • Nome provider: nome del provider.
      • ID fornitore: ID del fornitore. Non potrai modificare l'ID fornitore in un secondo momento.
      • URL emittente: https://app.terraform.io
      • Segmenti di pubblico: Segmento di pubblico predefinito

    5. Fai clic su Continua.

    6. In Configura attributi del provider, aggiungi le mappature degli attributi che hai identificato in precedenza.

    7. In Condizioni degli attributi, inserisci la condizione dell'attributo che hai identificato in precedenza.

    8. Fai clic su Salva per creare il fornitore e il pool di identità del workload.

    gcloud

    1. Crea un nuovo pool di identità del workload:

      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à dei pool

    2. Aggiungi un provider di pool di identità del workload:

      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"

      Sostituisci i seguenti valori:

      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"

      Sostituisci i seguenti valori:

      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"

      Sostituisci i seguenti valori:

      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"

      Sostituisci i seguenti valori:

    Aggiorna la condizione degli attributi di un provider di identità del workload

    Questa sezione descrive come aggiornare la condizione dell'attributo in un provider di pool di identità del workload esistente per limitare l'accesso ai token emessi dalla tua organizzazione GitHub, dal tuo gruppo GitLab o dalla tua organizzazione Terraform Cloud.

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

    Console

    1. Nella Google Cloud console, vai alla pagina Pool di identità del workload.

      Vai a Pool di identità del workload

    2. Individua il pool di identità del workload che contiene il fornitore, quindi fai clic sull'icona Espandi nodo per il pool.

    3. Trova il fornitore del pool di identità del workload che vuoi modificare e fai clic su Modifica.

    4. In Condizioni degli attributi, inserisci la condizione dell'attributo che hai identificato in precedenza.

    5. Per aggiornare il fornitore e il pool di identità del workload, fai clic su Salva.

    gcloud

    Per aggiornare il provider del pool di identità del workload, 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:

    Autenticare una pipeline di deployment

    Devi eseguire questi passaggi per ogni flusso di lavoro GitHub Actions o spazio di lavoro Terraform Cloud.

    Consenti al carico di lavoro esterno di accedere alle risorse Google Cloud

    Per completare le istruzioni riportate più avanti in questa guida, devi configurare l'impersonificazione del service account come descritto in questa sezione.

    Per fornire al tuo workload l'accesso alle risorse Google Cloud , ti consigliamo di concedere l'accesso diretto alle risorse all'entità. In questo caso, il principal è l'utente federato. Alcuni prodotti Google Cloud hanno limitazioni dell'API Google Cloud. Se il tuo carico di lavoro chiama un endpoint API che presenta una limitazione, puoi invece utilizzare la rappresentazione dell'identità delaccount di serviziot. In questo caso, l'entità è il service accountGoogle Cloud , che funge da identità. Concedi l'accesso alaccount di serviziot sulla risorsa.

    Accesso diretto alle risorse

    Puoi concedere l'accesso a un'identità federata direttamente alle risorse utilizzando la console Google Cloud o gcloud CLI.

    Console

    Per utilizzare la console Google Cloud per concedere i ruoli IAM direttamente su una risorsa, devi andare alla pagina della risorsa e poi concedere il ruolo. L'esempio seguente mostra come accedere alla pagina Cloud Storage e concedere il ruolo Visualizzatore oggetti Storage (roles/storage.objectViewer) a un'identità federata direttamente in un bucket Cloud Storage.

    1. Nella console Google Cloud , vai alla pagina Bucket in Cloud Storage.

      Vai a Bucket

    2. Nell'elenco dei bucket, fai clic sul nome del bucket per cui vuoi concedere il ruolo.

    3. Seleziona la scheda Autorizzazioni nella parte superiore della pagina.

    4. Fai clic sul pulsante Concedi l'accesso.

      Viene visualizzata la finestra di dialogo Aggiungi entità.

    5. Nel campo Nuove entità, inserisci una o più identità che devono accedere al tuo bucket.

      Per argomento 

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

      Sostituisci quanto segue:

      • PROJECT_NUMBER: il numero del progetto
      • POOL_ID: l'ID pool di workload
      • SUBJECT: il soggetto individuale mappato dal tuo IdP, ad esempio administrator@example.com

      Per gruppo 

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

      Sostituisci quanto segue:

      • PROJECT_NUMBER: il numero del progetto
      • WORKLOAD_POOL_ID: l'ID pool di workload
      • GROUP: il gruppo mappato dal tuo IdP, ad esempio: administrator-group@example.com

      Per attributo 

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

      Sostituisci quanto segue:

      • PROJECT_NUMBER: il numero del progetto
      • WORKLOAD_POOL_ID: l'ID pool di workload
      • ATTRIBUTE_NAME: uno degli attributi mappati dal tuo IdP
      • ATTRIBUTE_VALUE: il valore dell'attributo

    6. Seleziona un ruolo (o più ruoli) dal menu a discesa Seleziona un ruolo. I ruoli selezionati vengono visualizzati nel riquadro con una breve descrizione delle autorizzazioni che concedono.

    7. Fai clic su Salva.

    gcloud

    Per utilizzare gcloud CLI per concedere ruoli IAM su una risorsa in un progetto, procedi nel seguente modo:

    1. Ottieni il numero del progetto in cui è definita la risorsa.

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

    2. Concedi l'accesso alla risorsa.

      Per utilizzare gcloud CLI per concedere il ruolo Visualizzatore oggetti Storage (roles/storage.objectViewer) alle identità esterne che soddisfano determinati criteri, esegui questo comando.

      Per argomento

      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"

      Per gruppo

      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"

      Per attributo

      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"

      Sostituisci quanto segue:

      • BUCKET_ID: il bucket a cui concedere l'accesso
      • PROJECT_NUMBER: il numero di progetto del progetto che contiene il pool di identità del workload.
      • POOL_ID: l'ID pool del pool di identità del workload
      • SUBJECT: il valore previsto per l'attributo che hai mappato su google.subject
      • GROUP: il valore previsto per l'attributo che hai mappato su google.groups
      • ATTRIBUTE_NAME: il nome di un attributo personalizzato nel mapping degli attributi
      • ATTRIBUTE_VALUE: il valore dell'attributo personalizzato nella mappatura degli attributi

      Puoi concedere ruoli su qualsiasi risorsa Google Cloud che supporta i criteri di autorizzazione IAM.

    Simulazione dell'identità dei service account

    1. Per creare un account di servizio per il workload esterno:

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

        Enable the APIs

      2. Crea un service account che rappresenti il workload. Ti consigliamo di utilizzare un account di servizio dedicato per ogni workload. Il account di servizio non deve trovarsi nello stesso progetto del pool di identità del carico di lavoro, ma devi fare riferimento al progetto che contiene il account di servizio.

      3. Concedi al account di servizio l'accesso alle risorse a cui vuoi che accedano le identità esterne.

    2. Per consentire all'identità federata di rappresentare il account di servizio, procedi nel seguente modo:

    Console

    Per utilizzare la console Google Cloud per concedere ruoli IAM a un'identità federata con account di servizio:

    Service Account nello stesso progetto

    1. Per concedere l'accesso utilizzando la simulazione dell'identità del account di servizio per un account di servizio nello stesso progetto:

      1. Vai alla pagina Pool di identità del workload.

        Vai a Pool di identità del workload

      2. Seleziona Concedi l'accesso.

      3. Nella finestra di dialogo Concedi l'accesso al service account, seleziona Concedi l'accesso utilizzando la simulazione dell'identità del service account.

      4. Nell'elenco Service account, seleziona il account di servizio per le identità esterne da rappresentare e procedi nel seguente modo:

      5. Per scegliere quali identità nel pool possono rappresentare l'account di servizio, esegui una delle seguenti azioni:

        • Per consentire solo a identità specifiche del pool di identità del workload di simulare l'identità del account di servizio, seleziona Solo le identità corrispondenti al filtro.

        • Nell'elenco Nome attributo, seleziona l'attributo in base al quale vuoi filtrare.

        • Nel campo Valore attributo, inserisci il valore previsto dell'attributo. Ad esempio, se utilizzi una mappatura degli attributi google.subject=assertion.sub, imposta il nome dell'attributo su subject e il valore dell'attributo sul valore dell'attestazione sub nei token emessi dal tuo IdP esterno.

      6. Per salvare la configurazione, fai clic su Salva e poi su Ignora.

    Service account in un altro progetto

    1. Per concedere l'accesso utilizzando la rappresentazione dell'account di servizio per un service account in un altro progetto, procedi nel seguente modo:

      1. Vai alla pagina Service Accounts.

        Vai a Service account

      2. Seleziona l'account di servizio che vuoi rappresentare.

      3. Fai clic su Gestisci accesso.

      4. Fai clic su Aggiungi entità.

      5. Nel campo Nuova entità, inserisci uno dei seguenti identificatori dell'entità per le identità nel tuo pool che rappresenteranno l'account di servizio.

        Per argomento 

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

        Sostituisci quanto segue:

        • PROJECT_NUMBER: il numero del progetto
        • POOL_ID: l'ID pool di workload
        • SUBJECT: il soggetto individuale mappato dal tuo IdP, ad esempio administrator@example.com

        Per gruppo 

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

        Sostituisci quanto segue:

        • PROJECT_NUMBER: il numero del progetto
        • WORKLOAD_POOL_ID: l'ID pool di workload
        • GROUP: il gruppo mappato dal tuo IdP, ad esempio: administrator-group@example.com

        Per attributo 

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

        Sostituisci quanto segue:

        • PROJECT_NUMBER: il numero del progetto
        • WORKLOAD_POOL_ID: l'ID pool di workload
        • ATTRIBUTE_NAME: uno degli attributi mappati dal tuo IdP
        • ATTRIBUTE_VALUE: il valore dell'attributo

        Per piscina

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

        Sostituisci quanto segue:

        • PROJECT_NUMBER: il numero del progetto
        • WORKLOAD_POOL_ID: l'ID pool di workload

      6. In Seleziona un ruolo, seleziona il ruolo Utente Workload Identity (roles/iam.workloadIdentityUser).

      7. Per salvare la configurazione, fai clic su Salva.

    gcloud

    Per concedere il ruolo Utente Workload Identity (roles/iam.workloadIdentityUser) a un'entità federata o a un insieme di entità, esegui questo comando. Per scoprire di più sugli identificatori dei principal della federazione delle identità per i workload, consulta Tipi di principal.

    Per argomento

    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 del account di servizio
    • PROJECT_NUMBER: il numero di progetto del progetto che contiene il pool di identità del workload.
    • POOL_ID: l'ID pool del pool di identità del workload
    • SUBJECT: il valore previsto per l'attributo che hai mappato su google.subject
    • GROUP: il valore previsto per l'attributo che hai mappato su google.groups
    • ATTRIBUTE_NAME: il nome di un attributo personalizzato nel mapping degli attributi
    • ATTRIBUTE_VALUE: il valore dell'attributo personalizzato nella mappatura degli attributi

    Configura la pipeline di deployment

    Questa sezione descrive come utilizzare la federazione di Workload Identity nella pipeline di deployment. Le istruzioni in questa sezione presuppongono che i tuoi carichi di lavoro utilizzino l'impersonificazione dell'account di servizio per accedere alle risorse Google Cloud.

    Azure DevOps

    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 di servizio.
    • PROJECT_NUMBER: il numero di progetto del progetto che contiene il pool di identità del workload.
    • POOL_ID: l'ID del pool di identità del workload.
    • PROVIDER_ID: l'ID del fornitore del pool di identità del workload.
    • SERVICE_ACCOUNT_EMAIL: l'indirizzo email del account di servizio, se utilizzi l'imitazione del account di servizio. Se utilizzi l'accesso diretto alle risorse, ometti GoogleCloud.WorkloadIdentity.ServiceAccount e service_account_impersonation_url.

    La configurazione esegue le seguenti operazioni:

    1. Utilizza l'attività AzureCLI per ottenere un token ID per la connessione al servizio e lo rende disponibile in una variabile denominata idToken.
    2. Salva il token ID in un file temporaneo denominato .workload_identity.jwt.
    3. 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 rappresentare uaccount di serviziont.
    4. Imposta la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS in modo che punti al file di configurazione delle credenziali.

    GitHub Actions

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

    Modifica il file YAML di GitHub Actions 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 quanto segue:

    • PROJECT_NUMBER: Il numero di progetto del progetto che contiene il pool di identità del workload.
    • POOL_ID: l'ID del pool di identità del workload.
    • PROVIDER_ID: l'ID del fornitore del pool di identità del workload.
    • SERVICE_ACCOUNT_EMAIL: l'indirizzo email del account di servizio, se utilizzi la simulazione dell'identità del account di servizio. Se utilizzi l'accesso diretto alle risorse, ometti service_account.

    L'esempio seguente configura l'azione 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'

    Per ulteriori dettagli sull'utilizzo dell'azione google-github-actions/auth, consulta la pagina Configurazione della federazione delle identità per i workload.

    GitLab SaaS

    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 di progetto del progetto che contiene il pool di identità del workload.
    • POOL_ID: l'ID del pool di identità del workload.
    • PROVIDER_ID: l'ID del fornitore del pool di identità del workload.
    • SERVICE_ACCOUNT_EMAIL: l'indirizzo email del account di servizio, se utilizzi l'imitazione del account di servizio. Se utilizzi l'accesso diretto alle risorse, ometti SERVICE_ACCOUNT e service_account_impersonation_url.

    La configurazione esegue le seguenti operazioni:

    1. Indica a GitLab di emettere un token ID e lo rende disponibile nella variabile di ambiente denominata WORKLOAD_IDENTITY_TOKEN. Il token ID utilizza il provider del pool di identità del workload come pubblico.
    2. Salva il token ID in un file temporaneo denominato .workload_identity.jwt.
    3. 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 simulare uaccount di serviziont.
    4. Imposta la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS in modo che punti al file di configurazione delle credenziali.

    Terraform Cloud

    Configura il tuo spazio di lavoro Terraform Cloud in modo che utilizzi la federazione delle identità per i carichi di lavoro per l'autenticazione a Google Cloud utilizzando la rappresentazione dell'account di servizio:

    1. In Terraform Cloud, apri il tuo workspace e vai a Variabili.

    2. Aggiungi le seguenti variabili:

      Categoria della variabile Chiave Valore
      Variabile di ambiente TFC_GCP_PROVIDER_AUTH true
      Variabile di ambiente TFC_GCP_RUN_SERVICE_ACCOUNT_EMAIL L'indirizzo email del account di servizio, se utilizzi la simulazione dell'identità del service account, ad esempio terraform@my-project-123.iam.gserviceaccount.com. Ometti questa variabile di ambiente se utilizzi l'accesso diretto alle risorse.
      Variabile di ambiente TFC_GCP_PROJECT_NUMBER Il numero del progetto contenente il pool di identità del workload
      Variabile di ambiente TFC_GCP_WORKLOAD_POOL_ID L'ID del pool di identità del workload
      Variabile di ambiente TFC_GCP_WORKLOAD_PROVIDER_ID L'ID del provider di pool di identità per i carichi di lavoro

      Se utilizzi l'impersonificazione del account di servizio, puoi aggiungere variabili di ambiente aggiuntive per consentire a Terraform Cloud di utilizzare service account diversi per le fasi plan e apply. Per ulteriori informazioni sull'utilizzo delle variabili di ambiente nelle configurazioni Terraform, consulta Variabili di ambiente facoltative.

    3. Nell'elenco delle variabili, verifica che Categoria sia impostata su env per le cinque variabili che hai aggiunto nel passaggio precedente.

    4. Verifica che la configurazione Terraform utilizzi la versione 4.48.0 o successive del provider Google Cloud e aggiornala se necessario, nel seguente modo:

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

    5. Invia le modifiche al repository di codice sorgente.

    Passaggi successivi