Federazione delle identità per i workload

La federazione delle identità per i workload ti consente di concedere ai workload on-premise o multi-cloud l'accesso alle risorse Google Cloud utilizzando identità federate anziché chiavi dei account di servizio.

Puoi configurare la federazione per i servizi e le pipeline che eseguono una delle seguenti operazioni:

Perché utilizzare la federazione delle identità per i workload?

Le applicazioni in esecuzione al di fuori di Google Cloud possono utilizzare chiavi dei service account per accedere alle risorse Google Cloud . Tuttavia, le chiavi dei account di servizio sono credenziali importanti e possono rappresentare un rischio per la sicurezza se non vengono gestite correttamente. La federazione delle identità per i workload elimina gli oneri di manutenzione e sicurezza associati alle chiavi dei account di servizio.

Con la federazione delle identità per i workload, puoi utilizzare Identity and Access Management (IAM) per concedere ruoli IAM alle entità in base alle identità federate in un pool di identità del workload. Puoi concedere l'accesso alle entità su risorse Google Cloud specifiche. Questo approccio è chiamato accesso diretto. In alternativa, puoi concedere l'accesso a un account di servizio, che può quindi accedere alle risorse Google Cloud . Questo approccio è chiamato simulazione dell'identità dei service account.

Pool di identità del workload

Un pool di identità del workload è un'entità che consente di gestire le identità esterne.

In generale, ti consigliamo di creare un nuovo pool per ogni ambiente nonGoogle Cloudche deve accedere alle risorse Google Cloud , ad esempio ambienti di sviluppo, gestione temporanea o produzione.

Provider di pool di identità del workload

Un provider di pool di identità del workload è un'entità che descrive una relazione tra Google Cloud e il tuo IdP, tra cui:

  • AWS
  • Microsoft Entra ID
  • GitHub
  • GitLab
  • Cluster Kubernetes
  • Okta
  • Active Directory Federation Services (AD FS) on-premise
  • Terraform

La federazione delle identità per i workload segue la specifica dello scambio di token OAuth 2.0. Fornisci una credenziale del tuo IdP a Security Token Service, che verifica l'identità sulla credenziale e restituisce un token federato in cambio.

Provider OIDC con JWK locali

Per federare i workload che non hanno un endpoint OIDC pubblico, puoi caricare i set di chiavi web JSON (JWKS) OIDC direttamente nel pool. Questo è comune se hai Terraform o GitHub Enterprise ospitati nel tuo ambiente o se hai requisiti normativi che non consentono di esporre URL pubblici. Per ulteriori informazioni, consulta Gestisci i JWK OIDC (facoltativo).

Mappature degli attributi

I token emessi dall'IdP esterno contengono uno o più attributi. Alcuni IdP fanno riferimento a questi attributi come attestazioni.

I token di Google Security Token Service contengono anche uno o più attributi, come elencato nella tabella seguente:

Attributo Descrizione
google.subject Obbligatorio. Un identificatore univoco dell'utente. Questo attributo viene utilizzato nelle associazioni dei ruoli IAM principal:// e viene visualizzato nei log di Cloud Logging. Il valore deve essere univoco e non può superare i 127 caratteri.
google.groups Facoltativo. Un insieme di gruppi a cui appartiene l'identità. Questo attributo viene utilizzato nelle associazioni dei ruoli IAM principalSet:// per concedere l'accesso a tutti i membri di un gruppo.
attribute.NAME Facoltativo. Puoi definire fino a 50 attributi personalizzati e utilizzarli nelle associazioni di ruoli IAM principalSet:// per concedere l'accesso a tutte le identità con un determinato attributo.

Una mappatura degli attributi definisce come ricavare il valore dell'attributo del token di Google Security Token Service da un token esterno. Per ogni attributo del token di Google Security Token Service, puoi definire una mappatura degli attributi, formattata come segue:

TARGET_ATTRIBUTE=SOURCE_EXPRESSION

Sostituisci quanto segue:

  • TARGET_ATTRIBUTE è un attributo del token del servizio token di sicurezza Google
  • SOURCE_EXPRESSION è un'espressione Common Expression Language (CEL) che trasforma uno o più attributi dei token emessi dal tuo IdP esterno

Il seguente elenco fornisce esempi di mappatura degli attributi:

  • Assegna l'attributo di asserzione sub a google.subject:

    google.subject=assertion.sub

  • Concatena più attributi di asserzione:

    google.subject='myprovider::' + assertion.aud + '::' + assertion.sub

  • Mappa un attributo di asserzione con valore GUID workload_id a un nome e assegna il risultato a un attributo personalizzato denominato attribute.my_display_name:

    attribute.my_display_name={
  "8bb39bdb-1cc5-4447-b7db-a19e920eb111": "Workload1",
  "55d36609-9bcf-48e0-a366-a3cf19027d2a": "Workload2"
}[assertion.workload_id]

  • Utilizza operatori e funzioni logici CEL per impostare un attributo personalizzato denominato attribute.environment su prod o test, a seconda dell'Amazon Resource Name (ARN) dell'identità:

    attribute.environment=assertion.arn.contains(":instance-profile/Production") ? "prod" : "test"

  • Utilizza la funzione extract per compilare un attributo personalizzato aws_role con il nome del ruolo assunto o, se non è stato assunto alcun ruolo, con l'ARN dell'identità.

    attribute.aws_role=assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn

  • Utilizza la funzione split per suddividere una stringa in base a un separatore specificato. Ad esempio, per estrarre l'attributo username da un attributo dell'indirizzo email suddividendo il suo valore in corrispondenza del simbolo @ e utilizzando la prima stringa, utilizza la seguente mappatura degli attributi:

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

  • Utilizza la funzione join per unire un elenco di stringhe su un separatore specificato. Ad esempio, per compilare l'attributo personalizzato department concatenando un elenco di stringhe con . come separatore, utilizza la seguente mappatura degli attributi:

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

Quando utilizzi i certificati client X.509, la federazione delle identità per i workload mappa google.subject al nome comune dell'oggetto del certificato client (assertion.subject.dn.cn) per impostazione predefinita:

google.subject=assertion.subject.dn.cn

Puoi anche mappare attributi aggiuntivi dai certificati foglia e intermedi.

Per AWS, se non specifichi una mappatura degli attributi, Google applica la seguente mappatura predefinita, che copre gli scenari più comuni:

google.subject=assertion.arn
attribute.aws_role=assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn

Questa mappatura imposta google.subject sull'ARN del chiamante e imposta attribute.aws_role sull'ARN del ruolo assunto (senza il nome della sessione) se viene assunto un ruolo o sull'ARN del chiamante in caso contrario. Puoi anche fornire mappature personalizzate.

Per i provider OIDC e SAML, devi fornire le mappature degli attributi. Per creare la mappatura, consulta la documentazione del provider per un elenco degli attributi delle sue credenziali.

Per maggiori dettagli, consulta la documentazione dell'API per il campo attributeMapping.

Condizioni attributi

Una condizione dell'attributo è un'espressione CEL che può controllare gli attributi di 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.

Puoi utilizzare una condizione dell'attributo per limitare le identità che possono autenticarsi utilizzando il pool di identità del workload.

Le condizioni degli attributi sono utili in scenari come i seguenti:

  • Se il tuo workload utilizza un IdP disponibile al pubblico, puoi limitare l'accesso in modo che solo le identità che scegli abbiano accesso al pool di identità del workload.

  • Se utilizzi un IdP con più piattaforme cloud, puoi impedire che le credenziali destinate all'utilizzo con un'altra piattaforma vengano utilizzate con Google Cloude viceversa. In questo modo, eviti il problema del deputy confuso.

La condizione dell'attributo per un provider di pool di identità del workload può utilizzare la parola chiave assertion, che fa riferimento a una mappa che rappresenta la credenziale di autenticazione emessa dall'IdP. Puoi utilizzare la notazione con punto per accedere ai valori della mappa. Ad esempio, le credenziali AWS includono un valore arn, a cui puoi accedere come assertion.arn. Inoltre, la condizione dell'attributo può utilizzare qualsiasi attributo definito nella mappatura degli attributi del provider.

L'esempio seguente consente solo le richieste provenienti da identità con un ruolo AWS specifico:

attribute.aws_role == "ROLE_MAPPING"

Per maggiori dettagli, consulta la documentazione dell'API per il campo attributeCondition.

Gestione degli accessi

Il flusso di scambio dei token restituisce un token di accesso federato. Puoi utilizzare questo token di accesso federato per concedere al tuo workload l'accesso per conto delle identità delle entità alle risorse Google Cloud e ottenere un token di accesso OAuth 2.0 di breve durata.

Puoi utilizzare questo token di accesso per fornire l'accesso IAM.

Ti consigliamo di utilizzare la federazione delle identità per i workload per fornire l'accesso direttamente a una risorsa Google Cloud . Sebbene la maggior parte delle API Google Cloud supporti la federazione delle identità per i workload, alcune API presentano limitazioni. In alternativa, puoi utilizzare la simulazione dell'identità dei service account.

Il token di accesso di breve durata ti consente di chiamare qualsiasi API Google Cloud a cui la risorsa o il account di servizio ha accesso.

Accesso diretto alle risorse

Puoi utilizzare l'accesso diretto alle risorse per concedere alla tua identità esterna l'accesso direttamente a una risorsa Google Cloud utilizzando ruoli specifici per la risorsa.

Alternativa: simulazione dell'identità dei service account

In alternativa alla concessione dell'accesso diretto alle risorse, puoi utilizzare la simulazione dell'identità dei service account.

Devi concedere al tuo account di servizio il ruolo Workload Identity User (roles/iam.workloadIdentityUser).

Ambiti e sicurezza delle entità

Puoi concedere l'accesso alle entità o a sottoinsiemi di entità utilizzando i tipi di entità.

Tipi di entità

La tabella seguente descrive come definire le entità come singoli individui e gruppi di identità:

Identità Formato dell'identificatore
Singola identità principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
Tutte le identità in un gruppo principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP_ID
Tutte le identità con un valore dell'attributo specifico principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE

Passaggi successivi