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 gestisci un servizio che consente ai clienti di analizzare o gestire dati o risorse, i tuoi clienti potrebbero voler accedere a dati o altre risorse nel loro ambiente Google Cloud. Ecco alcuni esempi di questi prodotti e servizi:

• 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 clienti potrebbero utilizzare l'RPA per flussi di lavoro come la creazione di progetti, la gestione dell'accesso o l'automazione delle 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 le loro risorse Google Cloud consentendo loro di utilizzare la federazione delle identità di carico di lavoro per accedere alle risorse Google Cloud. Alcuni esempi di servizi che consentono già ai propri clienti di utilizzare la federazione delle identità per i carichi di lavoro sono 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à di Workload è eliminare la necessità di chiavi dell'account di servizio consentendo ai clienti di federare il tuo prodotto o servizio con il loro ambiente Google Cloud. I tuoi clienti potranno quindi accedere alle loro risorse Google Cloud utilizzando un'identità affermata dal tuo prodotto o servizio.

Per consentire ai clienti di utilizzare la federazione delle identità per i carichi di lavoro, il tuo prodotto o servizio deve 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 durante il 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 ID hanno una durata limitata, devi assicurarti che un token ID superi la durata del relativo carico di lavoro o che i carichi di lavoro possano ottenere periodicamente nuovi token ID.

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

   Il token ID deve contenere almeno un claim che identifichi in modo univoco il workload. L'identificatore del workload deve essere immutabile.

   Per i prodotti o i servizi che supportano il multitenancy, il token deve contenere anche almeno un claim che identifichi in modo univoco il tenant. L'identificatore del tenant deve essere anche 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 su un endpoint accessibile pubblicamente che possa essere rilevato utilizzando il protocollo di rilevamento dell'emittente OpenID. Ad esempio, se i token di identità contengono un claim iss con il valore https://service.example.com/v1/, devi fornire un documento di configurazione del fornitore OpenID 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 può 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.

Distinguere tra token di identità e token di accesso

Nel contesto della federazione delle identità per i workload, 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 workload di identificare il carico di lavoro e distinguerlo da altri.

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 un carico di lavoro o sulle API a cui è consentito 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 token ID da più origini, tra cui:

• Un endpoint HTTP (credenziali basate su URL)
• Un file locale (credenziali basate su file)

Per ottenere token ID da altre origini, i 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 lavoro da parte dei tuoi clienti.

Utilizza URL di emittenti specifici per il 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 assegnare inavvertitamente a questi carichi di lavoro lo stesso nome e ID.

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

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 gli stessi URL emittente in più tenant e incorpora un ID tenant univoco nell'URL emittente, ad esempio https://saas.example.com/tenant-123/.

Consenti agli utenti di specificare il 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 scelgono di federare il tuo prodotto o servizio con più parti attendibili, potrebbero trovarsi in una situazione in cui il token ID di un carico di lavoro viene utilizzato inavvertitamente o in modo fraudolento per la parte attendibile sbagliata: ad esempio, un malintenzionato potrebbe ingannare un carico di lavoro facendogli rivelare un token ID destinato a un servizio di terze parti, per poi utilizzarlo per la federazione delle identità per i carichi di lavoro.

Per 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, gestisci una lista consentita per i segmenti di pubblico che i carichi di lavoro 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 non modificabili e non riutilizzabili nei claim dei token ID

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

Se un cliente crea un'associazione IAM che fa riferimento a un'affermazione mutabile, il suo workload potrebbe perdere accidentalmente l'accesso quando il valore dell'affermazione 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, gli utenti 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 rubare 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 le credenziali di Google solo quando vengono soddisfatti determinati criteri aggiuntivi.

Per consentire ai clienti di configurare queste limitazioni, includi nel token ID claim aggiuntivi contenenti informazioni sul contesto. Ecco alcuni esempi di informazioni contestuali:

• 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 workload utilizza un token di identità per eseguire uno scambio di token, la Federazione delle identità per i workload 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 influisce su Workload Identity Federation, ma potrebbe aumentare i rischi se un token ID viene accidentalmente divulgato. 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

• Scopri di più sulla federazione di Workload Identity.
• Scopri le best practice per l'utilizzo della federazione delle identità per i workload.