Consenti ai clienti di accedere alle loro risorse Google Cloud dal tuo prodotto o servizio

Questo documento descrive i requisiti e le best practice che puoi seguire per consentire ai clienti di utilizzare il tuo prodotto per accedere alle proprie risorse in Google Cloud senza utilizzare le chiavi degli account di servizio.

Se offri un prodotto o un servizio che consente ai clienti di analizzare o gestire o risorse, i clienti potrebbero voler accedere ai dati o ad altre risorse nel proprio ambiente Google Cloud. Esempi per tali prodotti e servizi includono:

  • Prodotti di analisi dei dati: i tuoi clienti potrebbero voler utilizzare questi prodotti per analizzare i propri dati in BigQuery.
  • Prodotti e servizi CI/CD: i tuoi clienti potrebbero utilizzare questi servizi per eseguire il deployment di infrastruttura e applicazioni nei loro progetti Google Cloud.
  • Robotic Process automation (RPA): i tuoi clienti potrebbero utilizzare l'RPA per flussi di lavoro come la creazione di progetti, la gestione degli accessi o l'automazione attività amministrative in Google Cloud.

Per autenticare i prodotti on-premise o Software as a Service (SaaS) su Google Cloud, i clienti si sono tradizionalmente affidati alle chiavi degli account di servizio, ma queste chiavi possono essere difficili da gestire e archiviare in modo sicuro.

In qualità di fornitore di un prodotto on-premise o SaaS, puoi aiutare i tuoi clienti a proteggere alle proprie risorse Google Cloud, consentendo l'utilizzo della federazione delle identità per i carichi di lavoro per accedere alle proprie risorse Google Cloud. Esempi di servizi che già consentono ai propri clienti di utilizzare la federazione delle identità per i carichi di lavoro includono Terraform Cloud, GitHub, e GitLab

Questo documento descrive come estendere il tuo prodotto per supportare la federazione delle identità di carico di lavoro e le best practice che puoi seguire. Questo documento presuppone che tu abbia familiarità con la federazione delle identità per i carichi di lavoro e con OpenID Connect.

Architettura

Lo scopo della federazione delle identità per i carichi di lavoro è eliminare la necessità di un account di servizio consentendo ai clienti di federare il tuo prodotto o servizio con nell'ambiente Google Cloud. I tuoi clienti potranno quindi accedere ai loro Risorse Google Cloud che utilizzano un'identità dichiarata dal tuo prodotto o servizio.

Per consentire ai tuoi clienti di utilizzare la federazione delle identità per i carichi di lavoro, il tuo prodotto o servizio devi implementare un sottoinsieme di OpenID Connect. In particolare, devi consentire ai carichi di lavoro di ottenere un token ID che soddisfi i seguenti criteri:

  • Il token identifica il carico di lavoro all'interno del prodotto o della piattaforma
  • Il token identifica l'istanza, il tenant o l'installazione del tuo prodotto o della tua piattaforma
  • Il token contiene una firma crittografica che Workload Identity Federation può utilizzare per verificare l'autenticità del token.

Requisiti

Per supportare la federazione di Workload Identity, devi assicurarti che il tuo prodotto o servizio soddisfi i seguenti requisiti:

  1. I carichi di lavoro hanno accesso a un token ID valido.

    In qualsiasi momento del ciclo di vita, un carico di lavoro deve avere accesso a un token ID che ne attesti l'identità e sia conforme ai requisiti definiti da OpenID Connect 1.0.

    Poiché i token di identità hanno una durata limitata, devi assicurarti che un token di identità superi la durata del relativo carico di lavoro o che i carichi di lavoro possano ottenere periodicamente nuovi token di identità.

  2. I token ID identificano in modo univoco il carico di lavoro.

    Il token ID deve contenere almeno una dichiarazione che identifichi in modo univoco carico di lavoro. L'identificatore del carico di lavoro deve essere immutabile.

    Per i prodotti o i servizi che supportano la multitenancy, il token deve contenere anche almeno una richiesta che identifichi il tenant in modo univoco. Anche l'identificatore tenant deve essere immutabile.

  3. I token di identità sono firmati, ma non criptati.

  4. I metadati del provider OpenID sono accessibili pubblicamente e possono essere rilevati dai token ID.

    Devi fornire un documento di configurazione del provider OpenID in una posizione pubblica endpoint accessibile che può essere rilevato utilizzando il protocollo di rilevamento dell'emittente OpenID. Ad esempio, se i token ID contengono un'attestazione iss con il valore https://service.example.com/v1/, devi fornire un provider OpenID documento di configurazione su https://service.example.com/v1/.well-known/openid-configuration, e l'endpoint deve essere accessibile pubblicamente su internet da qualsiasi indirizzo IP.

  5. Le chiavi di firma sono accessibili pubblicamente e possono essere rilevate dai metadati del provider OpenID.

    Devi fornire un documento JSON Web Key Set (JWKS) su un endpoint accessibile pubblicamente che possa essere rilevato dal campo jwks_uri nei metadati del provider OpenID.

Best practice

Quando estendi il tuo prodotto o servizio per supportare la Federazione delle identità per i carichi di lavoro, prendi in considerazione le seguenti best practice.

Best practice:

Distingui tra token di identità e token di accesso.
Esponi i token ID in modo compatibile con le librerie client.
Utilizza URL dell'emittente specifici per il tenant.
Consenti agli utenti di specificare il pubblico del token ID.
Utilizza identificatori non modificabili e non riutilizzabili nei claim degli ID token.
Includi informazioni di contesto nei token ID.
Limita la durata del token ID a 30-60 minuti.

Distinguere tra token di identità e token di accesso

Nel contesto della federazione delle identità per i carichi di lavoro, lo scopo di un token di identità è affermare l'identità del carico di lavoro: il token deve contenere informazioni sufficienti per consentire alla federazione delle identità per i carichi di lavoro di identificare il carico di lavoro e distinguerlo da altri carichi di lavoro.

A differenza dei token ID, i token di accesso hanno in genere uno scopo diverso: Vengono utilizzati per prendere decisioni di accesso e potrebbero contenere informazioni su le autorizzazioni di cui dispone un carico di lavoro o le API a cui può accedere.

Se il tuo prodotto o servizio utilizza token di accesso per scopi quali consentire ai carichi di lavoro di chiamare l'API del tuo prodotto, questi token di accesso potrebbero non essere adatti alla federazione di Workload Identity. Anziché riutilizzare i token di accesso come token ID, valuta la possibilità di introdurre un secondo tipo di token che corrisponda alla definizione di un token ID e consenti ai carichi di lavoro di utilizzarlo per la federazione di Workload Identity.

Esponi gli ID token in modo compatibile con le librerie client

Le librerie client di Google Cloud possono ottenere automaticamente i token ID provenienti da più fonti, tra cui:

  • Un endpoint HTTP (credenziali provenienti da URL)
  • Un file locale (credenziali provenienti dal file)

Per ottenere token ID da altre origini, i tuoi clienti potrebbero dover modificare il codice o implementare strumenti o librerie aggiuntivi. Se esponi i token ID in modo compatibile con le librerie client, puoi evitare questa complessità aggiuntiva e semplificare l'adozione della federazione delle identità di carico di lavoro da parte dei tuoi clienti.

Usa URL emittente specifici per tenant

I claim incorporati nel token ID di un carico di lavoro potrebbero essere univoci all'interno di un'istanza specifica del tuo prodotto o servizio, ma potrebbero non essere univoci in più istanze del tuo prodotto o servizio. Ad esempio, due dei tuoi clienti potrebbero utilizzare il tuo prodotto o servizio per eseguire il deployment di un carico di lavoro e assegnarlo inavvertitamente per carichi di lavoro con lo stesso nome e ID.

Workload Identity Federation tenta di compensare questa possibile mancanza di univocità verificando l'URL emittente (iss) dei token di identità e consentendo solo i token di un singolo emittente per pool di identità per i carichi di lavoro.

Se il tuo prodotto o servizio supporta il multitenancy, diversi clienti potrebbero condividere una singola istanza del prodotto o servizio e i token ID dei loro carichi di lavoro potrebbero utilizzare lo stesso URL emittente. L'utilizzo dello stesso URL emittente in più tenant può esporre i tuoi clienti ad attacchi di spoofing: ad esempio, un malintenzionato potrebbe creare un carico di lavoro nel proprio tenant, assegnargli lo stesso ID o nome di un carico di lavoro nel tenant della vittima e utilizzare il token ID del proprio carico di lavoro per rubare l'identità del carico di lavoro della vittima.

Per proteggere i tuoi clienti dagli attacchi di spoofing, evita di utilizzare lo stesso emittente URL per più tenant e incorporano un ID tenant univoco nell'URL dell'emittente, ad esempio esempio https://saas.example.com/tenant-123/.

Consenti agli utenti di specificare il segmento di pubblico del token ID

Alcuni dei carichi di lavoro del tuo cliente potrebbero dover accedere a Google Cloud nonché ad altri servizi di terze parti. Quando i clienti di federare il tuo prodotto o servizio con più partiti potrebbero trovarsi in una situazione in cui il token ID di un carico di lavoro viene inavvertitamente o utilizzati in modo doloso per la parte attendibile sbagliata: ad esempio, un utente malintenzionato potrebbe indurre con l'inganno un carico di lavoro a rivelare un token ID destinato a una terza parte e utilizzare il token ID per la federazione delle identità per i carichi di lavoro.

Per contribuire a evitare che i tuoi clienti cadano vittime di questi attacchi di rappresentante confuso, evita di utilizzare un segmento di pubblico statico (affermazione aud) nei token ID. Al contrario, consenti ai carichi di lavoro di specificare un segmento di pubblico quando ottengono un token ID e, facoltativamente, di gestire una lista consentita per i segmenti di pubblico che possono richiedere.

Per impostazione predefinita, la federazione delle identità per i carichi di lavoro si aspetta che il pubblico di un token ID corrisponda all'URL https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID. Assicurati che i carichi di lavoro possano utilizzare un URL come segmento di pubblico per i token ID e che la lunghezza dell'URL del segmento di pubblico sia inferiore a 180 caratteri.

Utilizza identificatori immutabili e non riutilizzabili nelle rivendicazioni dei token ID

Quando i clienti vogliono concedere a Google Cloud l'accesso a uno dei loro carichi di lavoro devono creare un'associazione IAM che faccia riferimento all'identità del carico di lavoro per soggetto, gruppo o attributo personalizzato. L'attributo soggetto, gruppo e personalizzato dell'identità del carico di lavoro è dedotto dalle rivendicazioni nel token ID del carico di lavoro.

Se un cliente crea un'associazione IAM che fa riferimento a una rivendicazione modificabile, carico di lavoro potrebbe perdere accidentalmente l'accesso quando il valore della richiesta cambia. Ad esempio, un cliente potrebbe creare un'associazione IAM che fa riferimento al nome del suo carico di lavoro. Se in seguito il carico di lavoro viene rinominato, l'associazione IAM potrebbe non essere più applicata.

Peggio ancora, i malintenzionati potrebbero tentare di ottenere l'accesso non autorizzato ad altre risorse rinominando deliberatamente i carichi di lavoro o modificando l'ambiente di un carico di lavoro per lo spoofing l'identità di un altro carico di lavoro.

Per aiutare i clienti a evitare questi problemi di spoofing, assicurati che i token ID contengano identificatori immutabili e che non possano essere riutilizzati.

Includi informazioni sul contesto nei token ID

Invece di concedere ai carichi di lavoro l'accesso incondizionato alle risorse Google Cloud, i clienti potrebbero voler limitare l'accesso in modo che un carico di lavoro possa ottenere quando vengono soddisfatti determinati criteri aggiuntivi.

Per consentire ai clienti di configurare queste limitazioni, includi altre rivendicazioni nella Token ID che contiene informazioni di contesto. Esempi di informazioni di contesto includono:

  • informazioni sull'utente che possiede o ha avviato il carico di lavoro
  • il motivo e il modo in cui è stato avviato il carico di lavoro
  • la richiesta attualmente gestita dal carico di lavoro

I clienti possono utilizzare questi claim per configurare le condizioni degli attributi o negli identificatori principali.

Limita la durata del token ID a 60 minuti

I token di identità hanno una durata limitata determinata dal claim exp. Quando un carico di lavoro utilizza un token di identità per eseguire uno scambio di token, la Federazione delle identità per i carichi di lavoro convalida la rivendicazione exp del token di identità ed emette un token STS valido per la durata del token di input, ma per un massimo di 1 ora.

L'utilizzo di token ID validi per più di un'ora non ha alcun effetto su Federazione delle identità per i carichi di lavoro, ma potrebbe aumentare i rischi se un token ID viene accidentalmente è trapelato. L'utilizzo di una durata notevolmente inferiore a 1 ora può contribuire a ridurre questi rischi, ma potrebbe comportare scambi di token frequenti e prestazioni ridotte.

Passaggi successivi