Credenziali dell'account di servizio

Come per qualsiasi entità, un account di servizio può autenticarsi con Google, ottenere un token di accesso OAuth 2.0 e chiamare le API di Google. Tuttavia, questo processo funziona in modo diverso per gli account di servizio rispetto agli utenti.

Gli account di servizio eseguono l'autenticazione effettuando una delle seguenti operazioni:

• Ottenere credenziali di breve durata
• Utilizzare una chiave dell'account di servizio per firmare un token JWT (JSON Web Token) e scambiarlo con un token di accesso

Credenziali per account di servizio di breve durata

Il modo più sicuro per autenticarsi come account di servizio è ottenere credenziali di breve durata per l'account di servizio sotto forma di token di accesso OAuth 2.0. Per impostazione predefinita, questi token scadono dopo un'ora.

Le credenziali degli account di servizio di breve durata sono utili per gli scenari in cui è necessario concedere accesso limitato alle risorse per gli account di servizio attendibili. Creano anche meno rischi rispetto alle credenziali di lunga durata, come le chiavi degli account di servizio.

In molti casi, queste credenziali vengono ottenute automaticamente, quindi non è necessario crearle o gestirle personalmente. Ecco alcuni esempi:

• Se esegui un comando Google Cloud CLI e includi il flag --impersonate-service-account, gcloud CLI crea credenziali di breve durata per l'account di servizio ed esegue il comando con quelle credenziali.

• Se colleghi un account di servizio a un'istanza di macchina virtuale (VM) Compute Engine, i carichi di lavoro su quell'istanza possono utilizzare le librerie client di Cloud per accedere ai servizi Google Cloud. Le librerie client di Cloud utilizzano le Credenziali predefinite dell'applicazione (ADC) per ottenere credenziali di breve durata per l'account di servizio.

  Per maggiori dettagli su questo processo, consulta Autenticazione delle applicazioni utilizzando le credenziali degli account di servizio.

• Se hai configurato la federazione delle identità per i carichi di lavoro, le librerie client di Cloud possono utilizzare le credenziali del tuo provider di identità per generare credenziali per gli account di servizio di breve durata.

Puoi anche utilizzare l'API Service Account Credentials per creare manualmente le credenziali di breve durata. Ad esempio, potresti creare un servizio che fornisce agli utenti credenziali di breve durata per gli account di servizio per consentire loro di accedere temporaneamente alle risorse Google Cloud.

L'API Service Account Credentials può creare i seguenti tipi di credenziali:

• Token di accesso OAuth 2.0
• Token ID OpenID Connect (OIDC)
• Token web JSON autofirmati (JWT)
• BLOB binari autofirmati

Per saperne di più, consulta la sezione sulla creazione di credenziali per gli account di servizio di breve durata.

Interpretazione degli audit log

Cloud Audit Logs ti aiuta a rispondere alle domande "chi ha fatto cosa, dove e quando?" per le tue risorse Google Cloud.

Quando utilizzi credenziali di breve durata per impersonare un account di servizio, la maggior parte dei servizi Google Cloud crea voci di log che mostrano le seguenti identità:

• L'account di servizio che si spaccia per le credenziali di breve durata
• L'identità che ha creato le credenziali di breve durata

Puoi utilizzare queste voci di log per identificare l'entità che ha creato le credenziali di breve durata, nonché l'account di servizio che è stato rappresentato dall'entità.

Nota: alcuni servizi Google Cloud, tra cui App Engine e Google Kubernetes Engine, non registrano l'identità che ha creato le credenziali di breve durata.

Per esempi di voci di audit log che mostrano la simulazione dell'identità degli account di servizio, consulta Impersonificazione di un account di servizio per accedere a Google Cloud.

Furto d'identità

Per furto d'identità si intende l'utilizzo delle credenziali di un account di servizio per generare nuove credenziali per l'account di servizio.

L'API Service Account Credentials vieta i seguenti tipi di furto d'identità:

• Utilizzo di una credenziale di breve durata per un account di servizio al fine di generare un nuovo token di accesso per l'account di servizio.

  I token web JSON (Self-firmati) rappresentano l'eccezione a questa regola: puoi utilizzare un JWT autofirmato per un account di servizio al fine di generare un nuovo token di accesso per l'account di servizio.

• Utilizzo di una credenziale di breve durata per un account di servizio per firmare un oggetto binario (blob) o un JWT che può essere utilizzato per chiamare le seguenti API:

  • API Identity and Access Management
  • API Service Account Credentials
  • API OAuth 2.0

Google Cloud vieta questo tipo di rubare l'identità di sé perché consente agli aggressori malintenzionati di aggiornare i token rubati a tempo indeterminato.

Se provi a rubare l'identità di se stessi in uno dei modi vietati, potresti riscontrare il seguente errore:

FAILED_PRECONDITION: You can't create a token for the same service account that
you used to authenticate the request.

Se riscontri questo errore, prova a utilizzare credenziali diverse per generare le nuove credenziali di breve durata per il tuo account di servizio, ad esempio le credenziali dell'utente finale o quelle di un account di servizio diverso.

Chiavi account di servizio

Ogni account di servizio è associato a una coppia di chiave RSA pubblica/privata. L'API Service Account Credentials utilizza questa coppia di chiavi interna per creare credenziali per gli account di servizio di breve durata e per firmare BLOB e token JWT (JSON Web Token). Questa coppia di chiavi è nota come coppia di chiavi gestita da Google.

Inoltre, puoi creare più coppie di chiave RSA pubbliche/private, note come coppie di chiavi gestite dall'utente, e utilizzare la chiave privata per l'autenticazione con le API di Google. Questa chiave privata è nota come chiave dell'account di servizio.

Coppie di chiavi gestite da Google

Le coppie di chiavi gestite da Google vengono utilizzate dall'API Service Account Credentials e da servizi Google Cloud come App Engine e Compute Engine per generare credenziali di breve durata per gli account di servizio.

Le coppie di chiavi gestite da Google vengono ruotate automaticamente e utilizzate per la firma per un massimo di due settimane. Il processo di rotazione è probabilistici; l'uso della nuova chiave aumenterà gradualmente e diminuirà gradualmente nel corso del ciclo di vita della chiave.

La chiave privata in una coppia di chiavi gestita da Google è sempre conservata presso il deposito a garanzia e non potrai mai accedervi direttamente.

La chiave pubblica in una coppia di chiavi gestita da Google è accessibile pubblicamente, in modo che chiunque possa verificare le firme create con la chiave privata. Puoi accedere alla chiave pubblica in diversi formati:

• Certificato X.509: https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL
• Chiave web JSON (JWK): https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL
• Formato non elaborato: https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL

Se scarichi e memorizzi nella cache la chiave pubblica, ti consigliamo di memorizzarla nella cache per un massimo di 24 ore per assicurarti di avere sempre la chiave attuale. Indipendentemente da quando recuperi la chiave pubblica, questa sarà valida per almeno 24 ore dopo averla recuperata.

Coppie di chiavi gestite dall'utente

Puoi creare coppie di chiavi gestite dall'utente per un account di servizio e poi utilizzare la chiave privata di ogni coppia di chiavi per l'autenticazione con le API di Google. Questa chiave privata è nota come chiave dell'account di servizio.

Le librerie client di Cloud possono utilizzare le chiavi degli account di servizio per ottenere automaticamente un token di accesso OAuth 2.0. Puoi anche utilizzare una chiave dell'account di servizio per firmare manualmente un JWT e poi utilizzare il JWT firmato per richiedere un token di accesso. Per maggiori dettagli, consulta l'articolo sull'utilizzo di OAuth 2.0 per le applicazioni server-server.

Attenzione: le chiavi degli account di servizio comportano un rischio per la sicurezza se non vengono gestite correttamente. Dovresti scegliere un'alternativa più sicura alle chiavi degli account di servizio quando è possibile. Se devi eseguire l'autenticazione con una chiave dell'account di servizio, sei responsabile della sicurezza della chiave privata e di altre operazioni descritte nelle Best practice per la gestione delle chiavi degli account di servizio. Se non ti viene consentito di creare una chiave dell'account di servizio, la creazione di chiavi dell'account di servizio potrebbe essere disabilitata per la tua organizzazione. Per maggiori informazioni, consulta Gestione di risorse dell'organizzazione sicure per impostazione predefinita.

Ogni account di servizio può avere fino a 10 chiavi dell'account di servizio. Google archivia solo la parte pubblica di una coppia di chiavi gestita dall'utente.

Esistono diversi modi per creare una coppia di chiavi gestita dall'utente per un account di servizio:

• Utilizza l'API IAM per creare automaticamente una coppia di chiavi gestita dall'utente. Google genera una coppia di chiave pubblica/privata, archivia solo la chiave pubblica e ti restituisce la chiave privata.
• Crea autonomamente una coppia di chiavi gestita dall'utente, quindi carica solo la chiave pubblica. Google non vede mai la chiave privata.

Le chiavi gestite dagli utenti sono credenziali importantissime. Per limitare l'utilizzo delle chiavi gestite dall'utente, puoi applicare i seguenti vincoli dei criteri dell'organizzazione in un'organizzazione, un progetto o una cartella:

• constraints/iam.disableServiceAccountKeyCreation: impedisce alle entità di creare chiavi per gli account di servizio gestite dall'utente.
• constraints/iam.disableServiceAccountKeyUpload: impedisce alle entità di caricare una chiave pubblica per un account di servizio.

Se applichi questi vincoli perché utilizzi la federazione delle identità per i carichi di lavoro, valuta la possibilità di utilizzare i vincoli dei criteri dell'organizzazione per la federazione delle identità per i carichi di lavoro per specificare quali provider di identità sono consentiti.

Tempi di scadenza per le chiavi gestite dall'utente

Per impostazione predefinita, quando crei una chiave dell'account di servizio gestita dall'utente, la chiave non scade mai. Puoi modificare questa impostazione predefinita impostando una scadenza per tutte le chiavi appena create nel progetto, nella cartella o nell'organizzazione. Una data di scadenza specifica il numero di ore durante le quali è valida una chiave appena creata.

Utilizza le date di scadenza quando hai bisogno di accedere temporaneamente a un sistema che richiede una chiave dell'account di servizio. Ad esempio, utilizza la data di scadenza quando svolgi le seguenti operazioni:

• Sviluppare codice in un ambiente non di produzione per un'applicazione che può autenticarsi solo con le chiavi degli account di servizio.
• Utilizzo di uno strumento di terze parti che può eseguire l'autenticazione solo con le chiavi degli account di servizio

Evita di utilizzare date di scadenza per questi scenari:

• Carichi di lavoro di produzione. In produzione, una chiave dell'account di servizio scaduta potrebbe causare un'interruzione accidentale. Puoi invece usare chiavi senza scadenza e gestire il relativo ciclo di vita conrotazione della chiavei.
• Carichi di lavoro non di produzione che richiedono l'accesso permanente, ad esempio una pipeline di integrazione continua (CI).
• Sistemi di rotazione della chiave che impediscono l'utilizzo di una chiave dopo un determinato periodo di tempo. Per scoprire di più sulle strategie di rotazione della chiave consigliate, consulta Rotazione delle chiavi dell'account di servizio.

Per evitare interruzioni, ti consigliamo di non impostare una data di scadenza a meno che il constraints/iam.disableServiceAccountKeyCreation vincolo dei criteri dell'organizzazione non sia in vigore per un periodo di tempo prolungato. Quando imposti una data di scadenza, devi anche interrompere l'applicazione del vincolo constraints/iam.disableServiceAccountKeyCreation. Per maggiori dettagli su questo vincolo, consulta Limitazione della durata delle chiavi degli account di servizio.

Importante: se il vincolo constraints/iam.disableServiceAccountKeyCreation non è stato applicato, devi lavorare a stretto contatto con gli utenti del progetto, della cartella o dell'organizzazione per verificare che nessuna delle risorse esistenti richieda chiavi permanenti dell'account di servizio. Se una risorsa richiede chiavi permanenti per gli account di servizio e imposti una data di scadenza, è probabile che causi un'interruzione.

Per impostare una scadenza:

1. Identifica il progetto, la cartella o l'organizzazione per cui vuoi impostare una data di scadenza per le chiavi degli account di servizio.
2. Aggiungi un criterio dell'organizzazione che applichi il vincolo constraints/iam.serviceAccountKeyExpiryHours. Dopo aver applicato questo vincolo al progetto, alla cartella o all'organizzazione, la data di scadenza si applica a tutte le chiavi dell'account di servizio appena create all'interno della risorsa padre. Le chiavi esistenti non sono interessate.

I tempi di scadenza sono misurati in ore. Come best practice, utilizza tempi di scadenza brevi, ad esempio 8 ore, 24 ore (1 giorno) o 168 ore (7 giorni). Tempi di scadenza brevi contribuiscono a garantire che il tuo team disponga di una procedura collaudata per l'aggiornamento delle chiavi. Inizia con la scadenza più breve che soddisfa le tue esigenze e aumentala solo se necessario.