Credenziali del service account

Come qualsiasi principal, 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 in modo diverso per gli account di servizio rispetto agli utenti.

I service account eseguono l'autenticazione in uno dei seguenti modi:

Credenziali di breve durata per gli account di servizio

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

Le credenziali del account di servizio di breve durata sono utili per gli scenari in cui devi concedere l'accesso limitato alle risorse per i service account attendibili. Inoltre, creano meno rischi rispetto alle credenziali di lunga durata, come le chiavi deiaccount di serviziot.

In molti casi, queste credenziali vengono ottenute automaticamente, quindi non devi 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 il account di servizio ed esegue il comando con queste credenziali.

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

    Per informazioni dettagliate su questa procedura, vedi Autenticazione delle applicazioni tramite le account di servizio account.

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

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

Per saperne di più, vedi Creazione di credenziali di 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 serviziGoogle Cloud crea voci di log che mostrano le seguenti identità:

  • Il account di servizio che le credenziali di breve durata impersonano
  • 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é il account di servizio rappresentato dall'entità.

Per esempi di voci del log di controllo che mostrano la simulazione dell'identità di un account di servizio, vedi Simulazione dell'identità di un account di servizio per accedere a Google Cloud.

Furto d'identità personale

L'auto-rappresentazione si verifica quando utilizzi le credenziali di un account di servizio per generare nuove credenziali per ilaccount di serviziot.

L'API Service Account Credentials vieta i seguenti tipi di auto-impersonificazione:

Google Cloud vieta questo tipo di auto-impersonificazione perché consente ad attori malintenzionati di aggiornare i token rubati all'infinito.

Se provi a utilizzare l'auto-impersonificazione 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 si verifica questo errore, prova a utilizzare credenziali diverse per generare le nuove credenziali temporanee per il 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 pubbliche/private. 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 coppiaGoogle-owned and managed key .

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 del service account.

Conserva sempre le chiavi del account di servizio in un luogo sicuro. Se non memorizzi le chiavi in modo sicuro, i malintenzionati possono trovarle e utilizzarle per accedere alle risorse a cui può accedere ilaccount di serviziot. Ti consigliamo vivamente di archiviare le chiavi in un archivio chiavi basato su hardware o software. Per ulteriori indicazioni su come archiviare in modo sicuro le chiavi dei account di servizio, consulta la sezione Protezione dall'escalation dei privilegi.

Google-owned and managed key coppie

Le coppieGoogle-owned and managed key 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 i service account.

Google-owned and managed keys che vengono utilizzate attivamente per la firma vengono ruotate regolarmente in base alle best practice di sicurezza. Il processo di rotazione è probabilistico; l'utilizzo della nuova chiave aumenterà e diminuirà gradualmente nel corso della durata della chiave.

La chiave privata in una Google-owned and managed key coppia viene sempre conservata in escrow e non puoi mai accedervi direttamente.

La chiave pubblica in una coppia è accessibile pubblicamente, in modo che chiunque possa verificare le firme create con la chiave privata. Google-owned and managed key Puoi accedere alla chiave pubblica in diversi formati:

  • Certificato X.509: https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL
  • JSON Web Key (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 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 l'autenticazione con le API di Google. Questa chiave privata è nota come chiave del service account.

Le librerie client 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 un JWT manualmente, quindi utilizzare il JWT firmato per richiedere un token di accesso. Per i dettagli, vedi Utilizzo di OAuth 2.0 per applicazioni da server a server.

Ogni service account 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 entità di creare chiavi 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 del account di servizio gestita dall'utente, la chiave non scade mai. Puoi modificare questa impostazione predefinita impostando un tempo di scadenza per tutte le chiavi appena create nel progetto, nella cartella o nell'organizzazione. Un tempo di scadenza specifica il numero di ore per cui una chiave appena creata è valida.

Utilizza i tempi di scadenza quando hai bisogno di un accesso temporaneo a un sistema che richiede una chiave delaccount di serviziot. Ad esempio, utilizza i tempi di scadenza quando esegui le seguenti operazioni:

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

Evita di utilizzare tempi di scadenza per questi scenari:

  • Workload di produzione. In produzione, una chiave del account di servizio scaduta potrebbe causare un'interruzione accidentale. Utilizza invece chiavi che non scadono e gestisci il loro 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 delle chiavi che impediscono l'utilizzo di una chiave dopo un periodo di tempo specificato. Per scoprire le strategie di rotazione della chiave consigliate, consulta Rotazione delle chiavi del service account.

Per evitare interruzioni, ti consigliamo di non impostare un'ora di scadenza a meno che il constraints/iam.disableServiceAccountKeyCreation vincolo dei criteri dell'organizzazione non sia in vigore da un periodo di tempo prolungato. Quando imposti un orario di scadenza, devi anche interrompere l'applicazione del vincolo constraints/iam.disableServiceAccountKeyCreation. Per informazioni dettagliate su questo vincolo, consulta Limitare la durata delle chiavi degli account di servizio.

Per impostare un orario di scadenza:

  1. Identifica il progetto, la cartella o l'organizzazione in cui vuoi impostare un tempo di scadenza per le chiavi delaccount di serviziot.
  2. Aggiungi una policy dell'organizzazione che applichi il vincolo constraints/iam.serviceAccountKeyExpiryHours. Dopo aver applicato questo vincolo al tuo progetto, alla tua cartella o alla tua organizzazione, il tempo di scadenza si applica a tutte le chiavi delaccount di serviziot appena create all'interno di questa 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 ben testata per l'aggiornamento delle chiavi. Inizia con il tempo di scadenza più breve che soddisfa le tue esigenze e aumentalo solo se necessario.