Credenziali dell'account di servizio

Come qualsiasi entità, un account di servizio può autenticarsi su Google, ottenere un token di accesso OAuth 2.0 e chiamare le API di Google. Tuttavia, questa procedura funziona diversamente per gli account di servizio rispetto agli utenti.

Gli account di servizio si autenticano in uno dei seguenti modi:

Credenziali dell'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 1 ora.

Le credenziali dell'account di servizio di breve durata sono utili per gli scenari in cui devi concedere l'accesso limitato alle risorse per account di servizio attendibili. Inoltre, presentano meno rischi rispetto alle credenziali permanenti, come le chiavi degli account di servizio.

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

Puoi anche utilizzare l'API Service Account Credentials per creare manualmente credenziali di breve durata. Ad esempio, puoi creare un servizio che fornisca agli utenti credenziali di account di servizio di breve durata per consentir 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 (JWT) autofirmati
  • Blob binari autofirmati

Per ulteriori informazioni, vedi Creare credenziali di breve durata per gli account di servizio.

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 rubare l'identità di un account di servizio, la maggior parte dei servizi Google Cloud crea voci di log che mostrano le seguenti identità:

  • L'account di servizio di cui le credenziali di breve durata simulano l'identità
  • L'identità che ha creato le credenziali di breve durata

Puoi utilizzare queste voci di log per identificare il principale che ha creato le credenziali di breve durata, nonché l'account di servizio che il principale ha impersonato.

Per esempi di voci dei log di controllo che mostrano l'impersonificazione degli account di servizio, consulta Impersonificazione di un account di servizio per accedere a Google Cloud.

Furto d'identità

L'usurpazione d'identità si verifica quando utilizzi le credenziali di un account di servizio per generare una nuova credenziale per l'account di servizio.

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

Google Cloud vieta questo tipo di furto d'identità perché consente agli autori malintenzionati di aggiornare a tempo indeterminato i token rubati.

Se provi a utilizzare la sostituzione di persona 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 la nuova credenziale di breve durata per il tuo account di servizio, ad esempio le credenziali dell'utente finale o quelle di un altro account di servizio.

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 dell'account di servizio di breve durata e per firmare blob e token web JSON (JWT). 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 autenticarti 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 dai servizi Google Cloud come App Engine e Compute Engine per generare credenziali di breve durata per gli account di servizio.

Le chiavi gestite da Google che vengono utilizzate attivamente per la firma vengono ruotate regolarmente in base alle best practice per la sicurezza. Il processo di rotazione è probabilistico; l'utilizzo della nuova chiave aumenterà gradualmente e diminuirà nel corso della sua vita.

La chiave privata in una coppia di chiavi gestita da Google viene sempre conservata in custodia 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 farlo per massimo 24 ore per assicurarti di avere sempre la chiave corrente. Indipendentemente dal momento in cui la recupero, la chiave pubblica sarà valida per almeno 24 ore dopo il recupero.

Coppie di chiavi gestite dall'utente

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

Le librerie client di Cloud possono utilizzare le chiavi dell'account di servizio per ottenere automaticamente un token di accesso OAuth 2.0. Puoi anche utilizzare una chiave del account di servizio per firmare manualmente un JWT, quindi utilizzare il JWT firmato per richiedere un token di accesso. Per maggiori dettagli, consulta Utilizzo di OAuth 2.0 per applicazioni da server a server.

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:

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 persone di creare chiavi dell'account di servizio gestite dall'utente.
  • constraints/iam.disableServiceAccountKeyUpload: impedisce ai principali 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, ti consigliamo 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 questo valore predefinito impostando una data di scadenza per tutte le chiavi appena create nel progetto, nella cartella o nell'organizzazione. Una data di scadenza specifica il numero di ore per cui è 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 le date di scadenza quando:

  • Sviluppo di codice in un ambiente di produzione per un'applicazione che può autenticarsi solo con le chiavi dell'account di servizio
  • Utilizzo di uno strumento di terze parti che può autenticarsi solo con le chiavi dell'account di servizio

Evita di utilizzare le date di scadenza per i seguenti scenari:

  • Workload di produzione. In produzione, una chiave dell'account di servizio scaduta potrebbe causare un'interruzione accidentale. Utilizza invece chiavi che non scadono e gestisci il loro ciclo di vita con rotazione della chiave.
  • Carichi di lavoro non di produzione che richiedono l'accesso permanente, ad esempio una pipeline di integrazione continua (CI).
  • Sistemi di rotazione delle chiavi che impediscono l'utilizzo di una chiave dopo un determinato periodo di tempo. Per scoprire le strategie di rotazione della chiave consigliate, consulta Rotazione delle chiavi dell'account di servizio.

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

Per impostare una data di scadenza:

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

Le date di scadenza sono misurate in ore. Come best practice, utilizza scadenze brevi, ad esempio 8 ore, 24 ore (1 giorno) o 168 ore (7 giorni). Tempi di scadenza brevi contribuiscono ad assicurare al tuo team una procedura ben testata per l'aggiornamento delle chiavi. Inizia con la data di scadenza più breve che soddisfa le tue esigenze e aumentala solo se necessario.