Configura 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 il deployment per l'autenticazione in Google Cloud.

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

  • Le pipeline DevOps di Azure possono utilizzare una connessione del servizio di federazione delle identità per i carichi di lavoro Microsoft Entra per ottenere un token ID che identifica in modo univoco il progetto DevOps di Azure.
  • 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 configurazione Terraform che identifica in modo univoco l'area di lavoro e all'ambiente.

Puoi configurare le pipeline di deployment in modo da utilizzare queste credenziali per l'autenticazione Google Cloud utilizzando 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

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 Python esempi in questa pagina in un ambiente di sviluppo locale, installa e inizializza l'interfaccia a riga di comando gcloud, quindi configura le credenziali predefinite dell'applicazione con le tue credenziali utente.

  1. Install the Google Cloud CLI.

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

    gcloud init

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

Per ulteriori informazioni, vedi 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 Ruolo IAM Amministratore pool di identità per il carico di lavoro (roles/iam.workloadIdentityPoolAdmin) nel progetto. Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite la ruoli o altri ruoli predefiniti ruoli.

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

Prepara l'IdP esterno

DevOps di Azure

Per consentire a una pipeline DevOps di Azure di autenticarsi in Google Cloud, devi prima e configurare una connessione al servizio per Azure Resource Manager. Questo collegamento consente alla pipeline di ottenere un token ID, che può poi essere scambiato con le credenziali di Google Cloud.

Per creare una connessione al servizio per Azure Resource Manager, segui questi passaggi:

  1. In Azure DevOps, apri il progetto e vai a Impostazioni progetto.
  2. Vai a Pipeline > Connessioni di servizio.
  3. Fai clic su Crea collegamento al servizio.
  4. Seleziona Azure Resource Manager.
  5. Fai clic su Avanti.
  6. Seleziona Federazione delle identità per i carichi di lavoro (automatico)
  7. Fai clic su Avanti.

  8. Configura le seguenti impostazioni:

    • Livello di ambito: seleziona un abbonamento.

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

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

  9. Fai clic su Salva.

In un passaggio successivo, ti serviranno l'emittente e l'identificatore dell'oggetto del collegamento al servizio. Per cercare questi dettagli, procedi nel seguente modo:

  1. Fai clic sulla connessione al servizio che hai appena creato.
  2. Fai clic su Gestisci entità servizio.
  3. Vai a Certificati e segreti > Credenziali federate.
  4. Fai clic sulla credenziale federata.

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

    • Issuer (Emittente): identifica in modo univoco la tua organizzazione Azure DevOps
    • Identificatore dell'oggetto: identifica in modo univoco la connessione al servizio

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

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

Azioni GitHub

Non è necessario apportare modifiche di configurazione nel tuo account GitHub.

Dopo aver configurato un pool di identità per i carichi di lavoro in modo che sia attendibile nel repository GitHub, puoi consentire ai flussi di lavoro in quel repository di utilizzare Token OIDC GitHub per ottenere credenziali Google Cloud di breve durata.

GitLab SaaS

Non è necessario apportare modifiche alla configurazione nel tuo account GitLab.

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

Terraform Cloud

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

Dopo aver configurato un pool di identità per i carichi di lavoro per considerare attendibile Terraform Cloud, puoi abilitare la federazione delle identità per i carichi di lavoro 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 iniziare a configurare la federazione delle identità per i carichi di lavoro, segui questi passaggi:

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

    Go to project selector

    2. È meglio usa un progetto dedicato per gestire i provider e i pool di identità per i carichi di lavoro.

  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

Definire una mappatura degli attributi

Le credenziali specifiche dell'ambiente della pipeline di deployment possono contenere più attributi, e devi decidere quale attributo usare 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 a Google Cloud.

DevOps di Azure

Il token ID DevOps di Azure include un'attestazione sub che contiene l'oggetto identificatore della connessione al servizio. L'identificatore dell'oggetto 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 nelle Azioni GitHub token OIDC. Queste chiavi di rivendicazione 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 di GitHub Actions può variare a seconda dell'evento source. Altri attributi della rivendicazione 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 oppure nome di un'organizzazione GitHub, ad esempio "google".

  • repository_owner_id: contiene l'ID proprietario univoco, ad esempio "1342004".

Questo elenco è un sottoinsieme dei possibili claim. Per un elenco completo, consulta la documentazione di GitHub relativa ai claim di esempio. Assicurati di mappare tutte le rivendicazioni che ritieni prevedi di utilizzarlo come condizioni per gli attributi o nell'ambito di un futuro 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 unico.
  • environment: l'ambiente a cui si applica il job.
  • ref_path: il riferimento Git, ad esempio refs/heads/main.

La seguente mappatura degli attributi imposta google.subject sull'affermazione sub dell'token ID di GitLab. Perché la rivendicazione 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 in base a repository e branch può essere utile se determinati branch (ad esempio main) richiedono un accesso alle risorse diverso rispetto ad altri branch (ad esempio i branch di funzionalità).

In alcuni casi, potrebbe essere sufficiente differenziare l'accesso solo per progetto o un gruppo. La mappatura seguente 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 attestazioni incorporate in Terraform Cloud Token OIDC, incluso il seguente

  • terraform_organization_id: contiene l'ID univoco dell'organizzazione, per esempio org-xxxxxxxxxxxxxxxx.
  • terraform_workspace_id: contiene l'ID univoco dell'area di lavoro, per esempio ws-xxxxxxxxxxxxxxxx.
  • terraform_workspace_name: contiene il nome visualizzato dell'area 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.

La seguente mappatura degli attributi imposta google.subject sul claim terraform_workspace_id del token OIDC di Terraform Cloud:

google.subject=assertion.terraform_workspace_id

Questa mappatura 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 che possono controllare gli attributi di asserzione e gli attributi target. Se la condizione dell'attributo ha valore true per una determinata credenziale, la credenziale viene accettata. In caso contrario, le credenziali vengono rifiutate. Devi avere un mappatura degli attributi per tutti i campi delle condizioni degli attributi.

Azure DevOps

Facoltativamente, utilizza una condizione dell'attributo per limitare l'accesso a alcune connessioni ai servizi. 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.

Azioni GitHub

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

assertion.repository_owner=='ORGANIZATION'

Sostituisci ORGANIZATION con il nome della tua organizzazione GitHub.

Facoltativamente, espandi la condizione dell'attributo per limitare l'accesso a un sottoinsieme di flussi di lavoro o branch. 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'

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 su nella home page del tuo gruppo GitLab.

Facoltativamente, estendi la condizione dell'attributo per limitare l'accesso a un sottoinsieme di a 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 degli attributi per limitare l'accesso ai token emessi dal tuo Organizzazione Terraform Cloud:

assertion.terraform_organization_id=='ORGANIZATION_ID'

Sostituisci ORGANIZATION_ID con l'ID univoco del tuo 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' && assertion.terraform_workspace_id=='WORKSPACE_ID'

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

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

Console

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

  2. In Crea un pool di identità, inserisci quanto segue:

    • Nome: nome del pool. Il nome viene utilizzato anche come ID del pool. Non puoi 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 provider:

    DevOps di Azure

    • Seleziona un provider: OpenID Connect (OIDC).
    • Nome provider: il nome del progetto Azure DevOps o una 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.
    • Issuer URL (URL emittente): l'emittente della connessione al servizio che 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 del provider: il nome del provider.
    • ID provider: ID del provider. Non puoi modificare l'ID provider in un secondo momento.
    • URL emittente: https://token.actions.githubusercontent.com/
    • Segmenti di pubblico: Pubblico predefinito

    GitLab SaaS

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

    Terraform Cloud

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

  5. Fai clic su Continua.

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

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

  8. Fai clic su Salva per creare il pool e il provider di identità per i carichi di lavoro.

gcloud

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

  2. Aggiungi un provider di pool di identità di Workload Identity:

    Azure DevOps 

    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:

    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/" \
    --allowed-audiences="api://AzureADTokenExchange" \
    --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 su un provider di identità per i carichi di lavoro

Questa sezione descrive come aggiornare la condizione dell'attributo su un modello esistente provider di pool di identità per i carichi di lavoro per limitare l'accesso ai token emessi dal tuo organizzazione GitHub, gruppo GitLab o organizzazione Terraform Cloud.

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

Console

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

    Vai a Pool Workload Identity

  2. Individua il pool di identità per i carichi di lavoro che contiene il provider, quindi fai clic sul pulsante Espandi nodo per piscina.

  3. Trova il provider del pool di identità per i carichi di lavoro che vuoi modificare e fai clic su Modifica.

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

  5. Per aggiornare il provider e il pool di identità per i carichi di lavoro, 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:

Autentica una pipeline di deployment

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

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

Per completare le istruzioni riportate più avanti in questa guida, devi configurare l'usurpazione di identità dell'account servizio come descritto in questa sezione.

Per fornire al tuo carico di lavoro l'accesso alle risorse Google Cloud, consigliamo di concedere l'accesso diretto alle risorse al principale. In questo caso, l'entità è l'utente federato. Alcuni prodotti Google Cloud includono Limitazioni delle API Google Cloud. Se il carico di lavoro chiama un endpoint API con una limitazione, puoi scegliere la simulazione dell'identità degli account di servizio. In questo caso, l'entità è l'account di servizio Google Cloud, che funge da identità. Concedi l'accesso all'account di servizio sulla risorsa.

Accesso diretto alle risorse

Puoi concedere l'accesso a un'identità federata direttamente sulle 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 concedere il ruolo. L'esempio seguente mostra come andare 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 il quale concedere il ruolo.

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

  4. Fai clic sulla 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: carico di lavoro ID pool
    • SUBJECT: il soggetto singolo mappato dal tuo IdP, ad esempioadministrator@example.com

    Per gruppo 

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

    Sostituisci quanto segue:

    • PROJECT_NUMBER: il progetto numero
    • WORKLOAD_POOL_ID: carico di lavoro ID pool
    • GROUP: il gruppo mappata 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 progetto numero
    • WORKLOAD_POOL_ID: l'ID del pool di carichi di lavoro
    • ATTRIBUTE_NAME: uno dei che sono stati mappati dal tuo IdP
    • ATTRIBUTE_VALUE: il valore dell'attributo

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

  7. Fai clic su Salva.

gcloud

Per utilizzare gcloud CLI per concedere ruoli IAM su un di una risorsa di un progetto, segui questi passaggi:

  1. Ottenere il numero del progetto in cui la risorsa viene definito.

    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) a identità esterne che soddisfano determinati criteri, esegui il seguente comando.

    Per soggetto

    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à 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 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
    • ATTRIBUTE_VALUE: il valore dell'attributo personalizzato nella mappatura degli attributi

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

Simulazione dell'identità degli account di servizio

  1. Per creare un account di servizio per il carico di lavoro esterno, segui questi passaggi:

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

      Enable the APIs

    2. Crea un account di servizio che rappresenta il carico di lavoro. Ti consigliamo di utilizzare un account di servizio dedicato per ogni carico di lavoro. Non è necessario che l'account di servizio si trovi nello stesso progetto per i carichi di lavoro, ma devi fare riferimento al progetto contiene l'account di servizio.

    3. Concedere all'account di servizio l'accesso alle risorse a cui vuoi che accedano identità esterne.

    4. Concedi il ruolo Utente Workload Identity (roles/iam.workloadIdentityUser) all'account di servizio.

  2. Per concedere l'accesso a un'identità federata utilizzando la simulazione dell'identità dell'account di servizio tramite la console Google Cloud o gcloud CLI:

Console

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

Account di servizio nello stesso progetto

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

    1. Vai alla pagina Pool Workload Identity.

      Vai ai pool di identità per i carichi di lavoro

    2. Seleziona Concedi accesso.

    3. Nella finestra di dialogo Concedi l'accesso all'account di servizio, seleziona Concedi l'accesso utilizzando la simulazione dell'identità degli account di servizio.

    4. Nell'elenco Account di servizio, seleziona la l'account di servizio per le identità esterne, e procedi nel seguente modo:

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

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

      • Nell'elenco Nome attributo, seleziona l'attributo. in base alle quali vuoi applicare un filtro.

      • 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'affermazione sub nei token emessi dal tuo provider di identità esterno.

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

Account di servizio in un altro progetto

  1. Per concedere l'accesso utilizzando la simulazione dell'identità degli account di servizio per un in un altro progetto, segui questi passaggi:

    1. Vai alla pagina Service Accounts.

      Vai a Service account

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

    3. Fai clic su Gestisci accesso.

    4. Fai clic su Aggiungi entità.

    5. Nel campo Nuova entità, inserisci uno dei seguenti identificatori principali per le identità nel pool che simuleranno 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: carico di lavoro ID pool
      • SUBJECT: il soggetto singolo mappato dal tuo IdP, ad esempioadministrator@example.com

      Per gruppo 

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

      Sostituisci quanto segue:

      • PROJECT_NUMBER: il progetto numero
      • WORKLOAD_POOL_ID: carico di lavoro ID pool
      • GROUP: il gruppo mappata 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 progetto numero
      • WORKLOAD_POOL_ID: l'ID del pool di carichi di lavoro
      • ATTRIBUTE_NAME: uno dei che sono stati mappati dal tuo IdP
      • ATTRIBUTE_VALUE: il valore dell'attributo

      Per pool

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

      Sostituisci quanto segue:

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

    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 utilizzare gcloud CLI per concedere il ruolo Utente Workload Identity (roles/iam.workloadIdentityUser) alle identità esterne che soddisfano determinati criteri, esegui il seguente comando.

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 per il servizio
  • PROJECT_NUMBER: il numero del 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 che hai mappato a google.subject
  • GROUP: il valore previsto per l'attributo che che hai mappato a google.groups
  • ATTRIBUTE_NAME: il nome di un attributo personalizzato nella mappatura 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 delle identità per i carichi di lavoro in pipeline di deployment. Le istruzioni in questa sezione presuppongono che i tuoi carichi di lavoro utilizzino l'usurpazione di identità dell'account di servizio per accedere alle risorse Google Cloud.

DevOps di Azure

Modifica il file azure-pipelines.yml e aggiungi quanto segue al tuo 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 le seguenti operazioni:

  1. Utilizza l'attività AzureCLI per ottenere un token ID per la connessione del 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 fornisce istruzioni alle librerie client per leggere il token ID da .workload_identity.jwt e utilizzarlo per rubare l'identità un account di servizio.
  4. Imposta la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS in modo che indichi il 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 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 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 dell'identità del carico di lavoro dal provider di pool.
  • SERVICE_ACCOUNT_EMAIL: sostituisci con l'indirizzo email dell'account di servizio.

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 sezione Configurare la federazione di Workload Identity.

GitLab SaaS

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

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 dell'identità del carico di lavoro fornitore di pool
  • SERVICE_ACCOUNT_EMAIL: l'indirizzo email del account di servizio

La configurazione effettua le seguenti operazioni:

  1. Indica a GitLab di emettere un token di identità e lo rende 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.
  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 rubare l'identità di un account di servizio.
  4. Imposta la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS in modo che indichi il file di configurazione delle credenziali.

Cloud Terraform

Configura la tua area di lavoro Terraform Cloud in modo che utilizzi Federazione delle identità per i carichi di lavoro per eseguire l'autenticazione in Google Cloud utilizzando simulazione dell'identità degli account di servizio:

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

  2. Aggiungi le seguenti variabili:

    Categoria di variabili 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 contenente il pool di identità di carico 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

    Facoltativamente, puoi aggiungere altre variabili di ambiente per consentire a Terrform Cloud utilizza account di servizio diversi per le fasi plan e apply. Per maggiori informazioni, consulta la sezione Variabili di ambiente facoltative.

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

  4. Verifica che la configurazione Terraform utilizzi la versione 4.48.0 o successiva del provider Google Cloud e, se necessario, aggiornalo come segue:

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

  5. Invia le modifiche al repository di codice sorgente.

Passaggi successivi