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

Questo articolo 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 ad altre risorse nel loro ambiente Google Cloud. Ecco alcuni esempi di tali 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 dell'infrastruttura e delle applicazioni nei loro progetti Google Cloud.
• Automazione dei processi robotici (RPA): i tuoi clienti potrebbero utilizzare l'RPA per flussi di lavoro come la creazione di progetti, la gestione degli accessi o l'automazione delle attività amministrative in Google Cloud.

Per autenticare i prodotti on-premise o SaaS (SaaS) su Google Cloud, i clienti fanno affidamento convenzionalmente sulle chiavi degli account di servizio, ma queste possono essere difficili da gestire e archiviare in modo sicuro.

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

Questo articolo descrive come estendere il prodotto per supportare la federazione delle identità per i carichi di lavoro e descrive la best practice che puoi seguire. L'articolo presuppone che tu conosca la federazione delle identità per i carichi di lavoro e OpenID Connect.

Architettura

Lo scopo della federazione delle identità per i carichi di lavoro è eliminare la necessità di utilizzare chiavi degli account di servizio consentendo ai clienti di federare il tuo prodotto o servizio con il loro ambiente Google Cloud. I tuoi clienti possono quindi accedere alle proprie risorse Google Cloud utilizzando 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 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 prodotto o della piattaforma
• Il token contiene una firma crittografica che la federazione delle identità per i carichi di lavoro può utilizzare per verificare l'autenticità

Requisiti

Per supportare la federazione delle identità per i carichi di lavoro, 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 suo ciclo di vita, un carico di lavoro deve avere accesso a un token ID che asseri l'identità del carico di lavoro e sia conforme ai requisiti definiti da OpenID Connect 1.0.

   Poiché i token ID hanno una durata limitata, devi assicurarti che superino il 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 una attestazione che identifica in modo univoco il carico di lavoro. L'identificatore del carico di lavoro deve essere immutabile.

   Per i prodotti o servizi che supportano l'architettura multi-tenancy, il token deve anche contenere almeno una attestazione che identifica in modo univoco il tenant. Anche l'identificatore tenant deve essere immutabile.

3. I token ID 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 ID contengono un'attestazione iss con il valore https://service.example.com/v1/, devi fornire un documento di configurazione del provider 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 set di chiavi web JSON (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.

Distinguere tra token di identità e di accesso

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

A differenza dei token ID, quelli di accesso hanno in genere uno scopo diverso: vengono utilizzati per prendere decisioni di accesso e potrebbero contenere informazioni sulle autorizzazioni di un carico di lavoro o sulle API a cui è consentito accedere.

Se il tuo prodotto o servizio attualmente utilizza token di accesso per scopi quali consentire ai carichi di lavoro di chiamare l'API del prodotto, questi token di accesso potrebbero non essere adatti per la federazione delle identità per i carichi di lavoro. Invece di riutilizzare i token di accesso come token ID, ti consigliamo di introdurre un secondo tipo di token che corrisponda alla definizione di un token ID e di consentire ai carichi di lavoro di utilizzare il token ID per la federazione delle identità dei carichi di lavoro.

Esponi i token ID in un 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 provenienti dall'URL)
• Un file locale (credenziali provenienti da file)

Per ottenere token ID da altre origini, i tuoi clienti potrebbero dover modificare il proprio codice o eseguire il deployment di strumenti o librerie aggiuntivi. Esponendo i token ID in un modo compatibile con le librerie client, puoi evitare questa complessità aggiuntiva e semplificare l'adozione della federazione delle identità per i carichi di lavoro per i tuoi clienti.

Usa URL emittente specifici per il tenant

Le attestazioni incorporate nel token ID di un carico di lavoro potrebbero essere univoche all'interno di un'istanza specifica del prodotto o servizio, ma potrebbero non essere univoche in più istanze del 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 lo stesso ID.

La federazione delle identità per i carichi di lavoro tenta di compensare questa possibile mancanza di univocità verificando l'URL dell'emittente (iss) dei token ID 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 l'architettura multi-tenancy, diversi clienti potrebbero condividere una singola istanza del prodotto o servizio e i token ID dei carichi di lavoro potrebbero utilizzare lo stesso URL dell'emittente. L'utilizzo dello stesso URL dell'emittente in più tenant può esporre i clienti ad attacchi di spoofing. Ad esempio, un utente 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 carico di lavoro per contraffare l'identità di quest'ultimo.

Per proteggere i tuoi clienti da attacchi di spoofing, evita di utilizzare gli stessi URL dell'emittente in più tenant e incorpora un ID tenant univoco nell'URL dell'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 e ad altri servizi di terze parti. Quando i clienti decidono di federare il tuo prodotto o servizio con più parti responsabili, 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 non affidabile. Ad esempio, un malintenzionato potrebbe indurre con l'inganno un carico di lavoro a rivelare un token ID destinato a un servizio di terze parti per poi utilizzare quel token ID per la federazione delle identità per i carichi di lavoro.

Per evitare che i tuoi clienti cadano vittime di attacchi di questo tipo confusi con un vice, evita di utilizzare un pubblico statico (rivendicazione aud) nei token ID. Puoi invece consentire ai carichi di lavoro di specificare un segmento di pubblico quando ricevono un token ID e, facoltativamente, di mantenere 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 prevede 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 i segmenti di pubblico possano contenere fino a 180 caratteri.

Utilizza identificatori immutabili non riutilizzabili nelle rivendicazioni 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 attributo personalizzato. L'oggetto, il gruppo e gli attributi personalizzati dell'identità del carico di lavoro derivano dalle attestazioni nel token ID del carico di lavoro.

Se un cliente crea un'associazione IAM che fa riferimento a una rivendicazione modificabile, il suo carico di lavoro potrebbe perdere accidentalmente l'accesso quando il valore della rivendicazione cambia. Ad esempio, un cliente potrebbe creare un'associazione IAM che fa riferimento al nome del proprio carico di lavoro. Se in seguito rinominano il carico di lavoro, 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 eseguire lo spoofing dell'identità di un altro carico di lavoro.

Per aiutare i clienti a prevenire questi problemi di spoofing, assicurati che i token ID contengano identificatori immutabili e 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 Google solo quando vengono soddisfatti determinati criteri aggiuntivi.

Per consentire ai clienti di configurare queste restrizioni, includi nel token ID rivendicazioni aggiuntive 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 la modalità di avvio del carico di lavoro
• la richiesta attualmente gestita dal carico di lavoro

I clienti possono utilizzare queste attestazioni per configurare le condizioni degli attributi o negli identificatori principali.

Limita la durata del token ID a 60 minuti

I token ID hanno una durata limitata determinata dalla rivendicazione exp. Quando un carico di lavoro utilizza un token ID per eseguire uno scambio di token, la federazione delle identità per i carichi di lavoro convalida l'attestazione exp del token ID e invia un token STS valido per tutto il tempo del token di input, ma al massimo per un'ora.

L'utilizzo di token ID validi per più di un'ora non ha alcun effetto sulla federazione delle identità dei carichi di lavoro, ma potrebbe aumentare i rischi in caso di perdita accidentale di un token ID. L'utilizzo di una durata notevolmente inferiore a un'ora può contribuire a ridurre questi rischi, ma potrebbe portare a frequenti scambi di token e ridurre le prestazioni.

Passaggi successivi

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