Creare credenziali di breve durata per più account di servizio

In questa pagina viene spiegato come utilizzare l'impersonificazione degli account di servizio per creare credenziali di breve durata basate su una catena di delega di account di servizio. Puoi utilizzare questo approccio quando devi eseguire una serie di chiamate di generazione di token prima di avere un token con le autorizzazioni necessarie per eseguire l'attività.

Se puoi generare un token con l'autorizzazione richiesta con una singola chiamata di generazione dei token, devi creare direttamente le credenziali di breve durata per quell'account di servizio, che è un approccio più semplice al furto d'identità degli account di servizio.

Informazioni sulla creazione di credenziali di breve durata

A seconda del tipo di token che crei, puoi utilizzare credenziali di breve durata per autenticare le chiamate alle API di Google, alle API di terze parti o alle applicazioni che richiedono token ID. Le credenziali di breve durata hanno una durata limitata, con una durata di poche ore o meno, e non vengono aggiornate automaticamente. Le credenziali dell'account di servizio di breve durata sono utili per gli scenari in cui devi concedere un accesso limitato alle risorse per gli account di servizio attendibili. Creano inoltre meno rischi rispetto alle credenziali di lunga durata, come le chiavi degli account di servizio.

Puoi creare i seguenti tipi di credenziali di breve durata impersonando un account di servizio:

  • Token di accesso OAuth 2.0

    I token di accesso sono accettati per l'autenticazione dalla maggior parte delle API di Google. Quando generi un token di accesso utilizzando la rappresentazione dell'account di servizio, il token di accesso viene fornito senza un token di aggiornamento, il che significa che alla scadenza del token, devi ripetere la procedura di rappresentazione per generare un nuovo token.

    Per ulteriori informazioni, vedi Token di accesso.

  • Token ID OpenID Connect (OIDC)

    I token ID seguono la specifica OpenID Connect (OIDC). I token ID sono accettati da un numero limitato di servizi e applicazioni.

    Per maggiori informazioni, consulta la pagina Token ID e Autenticazione per applicazioni ospitate su Cloud Run o Cloud Functions.

  • Token web JSON (JWT) autofirmati

    Puoi utilizzare i JWT autofirmati per eseguire l'autenticazione su alcune API di Google senza ottenere un token di accesso dal server di autorizzazione. Le API di cui è stato eseguito il deployment con API Gateway le richiedono.

  • Blob binari autofirmati

    I blob autofirmati sono utili negli scenari in cui devi trasmettere in modo sicuro dati binari arbitrari, solitamente ai fini dell'autenticazione.

Flusso di richiesta delegato

Il flusso di richieste delegate consente di concatenare le richieste dirette utilizzando una singola richiesta, anziché dover effettuare più richieste dirette in sequenza. In questo flusso, la richiesta di una credenziale dell'account di servizio viene delegata a uno o più account di servizio in una catena di delega prima di generare una credenziale per l'account di servizio finale. La credenziale risultante rappresenta solo l'account di servizio finale e non gli account di servizio intermedi nella catena di delega.

Ogni account di servizio nella catena di delega deve avere le autorizzazioni richieste sull'account di servizio successivo nella catena, in modo che possa trasmettere la richiesta.

Se un account di servizio fornisce tutte le autorizzazioni necessarie, devi utilizzare il flusso più semplice descritto in Creare credenziali di breve durata da un account di servizio.

Prima di iniziare

  • Abilita le API IAM and Service Account Credentials.

    Abilita le API

  • Informazioni sugli account di servizio IAM

  • Se non lo hai già fatto, abilita la fatturazione e l'API IAM seguendo i passaggi descritti nella guida rapida.

  • Identificare gli account di servizio che utilizzerai nella catena di delega.

    Se necessario, puoi creare un nuovo account di servizio e includerlo nella catena di delega.

Fornire le autorizzazioni richieste

Una richiesta delegata riguarda più di due identità: il chiamante, uno o più account di servizio in una catena di delega e infine l'account di servizio. In questo flusso, considera le seguenti identità:

  • Account di servizio 1 (SA_1), il chiamante che invia una richiesta di credenziali di breve durata.
  • Account di servizio 2 (SA_2), un account di servizio intermediario che delegherà la richiesta iniziale a SA_3. Questo account trasmette solo la richiesta e non concede alcun accesso aggiuntivo a SA_1 o SA_3.
  • Account di servizio 3 (SA_3), l'account con privilegi limitati per cui è stata creata la credenziale.

Per consentire la delega, ogni account deve concedere il ruolo Creatore token account di servizio (roles/iam.serviceAccountTokenCreator) all'account precedente nella catena.

In questo esempio particolare, a SA_1 deve essere concesso il ruolo Creatore token account di servizio (roles/iam.serviceAccountTokenCreator) per SA_2. Questo è un esempio di account di servizio SA_2 considerato come una risorsa: quando concedi il ruolo su SA_2, aggiorni il relativo criterio di autorizzazione come faresti per qualsiasi altra risorsa.

In questo flusso di esempio, è presente un solo account di servizio intermediario. Per delegare l'accesso tramite più di un account di servizio, devi assegnare questo ruolo anche a qualsiasi altro account di servizio nella catena.

In seguito, sarà necessario concedere a SA_2 anche il ruolo Creatore token account di servizio (roles/iam.serviceAccountTokenCreator) il giorno SA_3. In questo modo, SA_2 può creare credenziali di breve durata per SA_3.

I passaggi seguenti utilizzano l'API REST per concedere i ruoli. Tuttavia, puoi anche utilizzare la console Google Cloud o l'interfaccia a riga di comando gcloud.

API

Per prima cosa, recupera il criterio di autorizzazione per SA_2 (l'account di servizio dell'intermediario):

Il metodo serviceAccounts.getIamPolicy riceve il criterio di autorizzazione di un account di servizio.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • PROJECT_ID: l'ID del tuo progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, ad esempio my-project.
  • SA_2: il nome dell'account di servizio 2.
  • POLICY_VERSION: la versione del criterio da ripristinare. Le richieste devono specificare la versione del criterio più recente, ovvero la versione del criterio 3. Per maggiori dettagli, consulta Specificare la versione di un criterio quando si riceve un criterio.

Metodo e URL HTTP: 

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_2@PROJECT_ID.iam.gserviceaccount.com:getIamPolicy

Corpo JSON richiesta: 

{
  "options": {
    "requestedPolicyVersion": POLICY_VERSION
  }
}

Per inviare la richiesta, espandi una delle seguenti opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    }
  ]
}

Se non hai concesso un ruolo all'account di servizio, la risposta contiene solo un valore etag. Includi il valore etag nel passaggio successivo.

A questo punto, modifica il criterio di autorizzazione per concedere a SA_1 il ruolo Creatore token account di servizio (roles/iam.serviceAccountTokenCreator).

Ad esempio, per modificare la risposta di esempio al passaggio precedente, aggiungi quanto segue:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_1@PROJECT_ID.iam.gserviceaccount.com"
      ]
    }
  ]
}

Poi, scrivi il criterio di autorizzazione aggiornato per SA_2:

Il metodo serviceAccounts.setIamPolicy imposta un criterio di autorizzazione aggiornato per l'account di servizio.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • PROJECT_ID: l'ID del tuo progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, ad esempio my-project.
  • SA_2: il nome dell'account di servizio 2.

  • POLICY: una rappresentazione JSON del criterio che vuoi impostare. Per ulteriori informazioni sul formato di un criterio, consulta la documentazione di riferimento.

    Ad esempio, per impostare il criterio di autorizzazione mostrato nel passaggio precedente, sostituisci POLICY con il seguente:

    {
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_1@PROJECT_ID.iam.gserviceaccount.com"
      ]
    }
  ]
}

Metodo e URL HTTP: 

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_2@PROJECT_ID.iam.gserviceaccount.com:setIamPolicy

Corpo JSON richiesta: 

{
  "policy": POLICY
}

Per inviare la richiesta, espandi una delle seguenti opzioni:

La risposta contiene il criterio di autorizzazione aggiornato.

Ora recupera il criterio di autorizzazione per SA_3 (l'account di servizio per cui è stata creata la credenziale):

Il metodo serviceAccounts.getIamPolicy riceve il criterio di autorizzazione di un account di servizio.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • PROJECT_ID: l'ID del tuo progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, ad esempio my-project.
  • SA_3: il nome dell'account di servizio 3.
  • POLICY_VERSION: la versione del criterio da ripristinare. Le richieste devono specificare la versione del criterio più recente, ovvero la versione del criterio 3. Per maggiori dettagli, consulta Specificare la versione di un criterio quando si riceve un criterio.

Metodo e URL HTTP: 

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_3@PROJECT_ID.iam.gserviceaccount.com:getIamPolicy

Corpo JSON richiesta: 

{
  "options": {
    "requestedPolicyVersion": POLICY_VERSION
  }
}

Per inviare la richiesta, espandi una delle seguenti opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    }
  ]
}

Se non hai assegnato un ruolo all'account di servizio, la risposta contiene solo un valore etag. Includi il valore etag nel passaggio successivo.

A questo punto, modifica il criterio di autorizzazione per concedere a SA_2 il ruolo Creatore token account di servizio (roles/iam.serviceAccountTokenCreator).

Ad esempio, per modificare la risposta di esempio al passaggio precedente, aggiungi quanto segue:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_2@PROJECT_ID.iam.gserviceaccount.com"
      ]
    }
  ]
}

Infine, scrivi il criterio di autorizzazione aggiornato:

Il metodo serviceAccounts.setIamPolicy imposta un criterio di autorizzazione aggiornato per l'account di servizio.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • PROJECT_ID: l'ID del tuo progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, ad esempio my-project.
  • SA_3: il nome dell'account di servizio 3.

  • POLICY: una rappresentazione JSON del criterio che vuoi impostare. Per ulteriori informazioni sul formato di un criterio, consulta la documentazione di riferimento.

    Ad esempio, per impostare il criterio di autorizzazione mostrato nel passaggio precedente, sostituisci POLICY con il seguente:

    {
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_2@PROJECT_ID.iam.gserviceaccount.com"
      ]
    }
  ]
}

Metodo e URL HTTP: 

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_3@PROJECT_ID.iam.gserviceaccount.com:setIamPolicy

Corpo JSON richiesta: 

{
  "policy": POLICY
}

Per inviare la richiesta, espandi una delle seguenti opzioni:

La risposta contiene il criterio di autorizzazione aggiornato.

Richiedere credenziali di breve durata

Dopo aver concesso i ruoli appropriati a ogni identità, puoi richiedere credenziali di breve durata per l'account di servizio desiderato. Sono supportati i seguenti tipi di credenziali:

Per capire come specificare una catena di delega per queste richieste, consulta la sezione Specificare una catena di delega in questa pagina.

Generare un token di accesso OAuth 2.0

Per impostazione predefinita, i token di accesso OAuth 2.0 sono validi per un massimo di 1 ora (3600 secondi). Tuttavia, puoi estendere la durata massima di questi token a 12 ore (43.200 secondi). Per farlo, identifica gli account di servizio che necessitano di una durata estesa per i token, quindi aggiungi questi account di servizio a un criterio dell'organizzazione che include il vincolo dell'elenco constraints/iam.allowServiceAccountCredentialLifetimeExtension. Puoi quindi specificare una durata fino a 43.200 secondi quando crei un token per questi account di servizio.

Per generare un token di accesso OAuth 2.0 per un account di servizio, procedi nel seguente modo:

API

Il metodo serviceAccounts.generateAccessToken dell'API Service Account Credentials genera un token di accesso OAuth 2.0 per un account di servizio.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • SA_NAME: il nome dell'account di servizio per cui vuoi creare un token.
  • PROJECT_ID: l'ID del tuo progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, ad esempio my-project.
  • DELEGATES: se utilizzi un flusso di richiesta delegato, vedi Specificare una catena di delega in questa pagina. Se utilizzi un flusso di richiesta diretta senza delega, ometti il campo delegates nel corpo della richiesta.

  • LIFETIME: quantità di tempo prima della scadenza del token di accesso, in secondi. Ad esempio, 300s.

    Per impostazione predefinita, la durata massima del token è di 1 ora (3600 secondi). Per estendere la durata massima di questi token a 12 ore (43.200 secondi), aggiungi l'account di servizio a un criterio dell'organizzazione che include il vincolo dell'elenco constraints/iam.allowServiceAccountCredentialLifetimeExtension.

Metodo e URL HTTP: 

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com:generateAccessToken

Corpo JSON richiesta: 

{
  "delegates": [
    DELEGATES
  ],
  "scope": [
    "https://www.googleapis.com/auth/cloud-platform"
  ],
  "lifetime": "LIFETIME"
}

Per inviare la richiesta, espandi una delle seguenti opzioni:

Se la richiesta generateAccessToken ha avuto esito positivo, il corpo della risposta contiene un token di accesso OAuth 2.0 e una data di scadenza. accessToken può quindi essere utilizzato per autenticare una richiesta per conto dell'account di servizio finché non viene raggiunto il valore expireTime: 

{
  "accessToken": "eyJ0eXAi...NiJ9",
  "expireTime": "2020-04-07T15:01:23.045123456Z"
}

Generazione token ID OpenID Connect

I token ID OpenID Connect sono validi per 1 ora (3600 secondi). Per generare un token ID per un account di servizio, procedi nel seguente modo:

API

Il metodo serviceAccounts.generateIdToken dell'API Service Account Credentials genera un token ID OIDC per un account di servizio.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • PRIV_SA: l'indirizzo email dell'account di servizio con privilegi per i quali è stato creato il token di breve durata.
  • AUDIENCE_NAME: il pubblico per il token, in genere l'URL dell'applicazione o del servizio a cui il token verrà utilizzato per accedere.

Metodo e URL HTTP: 

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/PRIV_SA:generateIdToken

Corpo JSON richiesta: 

{
  "audience": "AUDIENCE_NAME",
  "includeEmail": "true"
}

Per inviare la richiesta, espandi una delle seguenti opzioni:

Se la richiesta generateId ha avuto esito positivo, il corpo della risposta contiene un token ID valido per 1 ora. token può quindi essere utilizzato per autenticare una richiesta per conto dell'account di servizio: 

{
  "token": "eyJ0eXAi...NiJ9"
}

Creazione di un token web JSON (JWT) autofirmato

I token web JSON (JWT) autofirmati sono utili in diversi scenari, ad esempio:

  • Autenticazione di una chiamata a un'API di Google come descritto nella Guida all'autenticazione di Google.
  • Comunicare in modo sicuro tra servizi Google Cloud e non Google, come le applicazioni App Engine. In questo scenario, un'applicazione può firmare un token che può essere verificato da un'altra applicazione ai fini dell'autenticazione.
  • Trattare un account di servizio come un provider di identità firmando un JWT che contiene affermazioni arbitrarie su un utente, un account o un dispositivo.

Per generare un JWT autofirmato per un account di servizio:

API

Il metodo serviceAccounts.signJwt dell'API Service Account Credentials firma un JWT utilizzando la chiave privata gestita dal sistema di un account di servizio.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • SA_NAME: il nome dell'account di servizio per cui vuoi creare un token.
  • PROJECT_ID: l'ID del tuo progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, ad esempio my-project.
  • DELEGATES: se utilizzi un flusso di richiesta delegato, vedi Specificare una catena di delega in questa pagina. Se utilizzi un flusso di richiesta diretta senza delega, ometti il campo delegates nel corpo della richiesta.

  • JWT_PAYLOAD: il payload JWT da firmare, ovvero un oggetto JSON contenente un set di rivendicazioni JWT. Includi le affermazioni necessarie per il caso d'uso desiderato e per soddisfare i requisiti di convalida del servizio richiesto. Se stai chiamando un'API di Google, consulta la Guida all'autenticazione di Google per i requisiti della dichiarazione.

    La rivendicazione di exp (ora di scadenza) non può superare le 12 ore nel futuro. Se stai chiamando un'API di Google, la rivendicazione del tipo exp non deve essere impostata su più di un'ora nel futuro.

    Il seguente payload di esempio contiene rivendicazioni per chiamare un'API di Google, dove EXP è un timestamp intero che rappresenta la data di scadenza: 

    { \"iss\": \"SA_NAME@PROJECT_ID.iam.gserviceaccount.com\", \"sub\": \"SA_NAME@PROJECT_ID.iam.gserviceaccount.com\", \"aud\": \"https://firestore.googleapis.com/\", \"iat\": 1529350000, \"exp\": EXP }

Metodo e URL HTTP: 

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com:signJwt

Corpo JSON richiesta: 

{
  "delegates": [
    DELEGATES
  ],
  "payload": "JWT_PAYLOAD"
}

Per inviare la richiesta, espandi una delle seguenti opzioni:

Se la richiesta signJwt ha avuto esito positivo, il corpo della risposta contiene un JWT firmato e l'ID della chiave di firma utilizzato per firmare il JWT. Puoi utilizzare il valore signedJwt come token di connessione per autenticare direttamente una richiesta per conto dell'account di servizio. Il token è valido fino alla data di scadenza specificata nella richiesta: 

{
  "keyId": "42ba1e...fc0a",
  "signedJwt": "eyJ0eXAi...NiJ9"
}

Creazione di un blob autofirmato

I blob autofirmati sono utili negli scenari in cui devi trasmettere in modo sicuro dati binari arbitrali, generalmente per l'autenticazione. Ad esempio, se vuoi utilizzare un protocollo/tipo di token personalizzato (non JWT), puoi includere questi dati in un blob firmato da utilizzare per un servizio a valle.

Per generare un blob autofirmato per un account di servizio, procedi nel seguente modo:

API

Il metodo serviceAccounts.signBlob dell'API Service Account Credentials firma un blob utilizzando la chiave privata gestita dal sistema di un account di servizio.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • SA_NAME: il nome dell'account di servizio per cui vuoi creare un token.
  • PROJECT_ID: l'ID del tuo progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, ad esempio my-project.
  • DELEGATES: se utilizzi un flusso di richiesta delegato, vedi Specificare una catena di delega in questa pagina. Se utilizzi un flusso di richiesta diretta senza delega, ometti il campo delegates nel corpo della richiesta.
  • BLOB_PAYLOAD: una stringa di byte codificata in base64. Ad esempio, VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wZWQgb3ZlciB0aGUgbGF6eSBkb2cu.

Metodo e URL HTTP: 

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com:signBlob

Corpo JSON richiesta: 

{
  "delegates": [
    DELEGATES
  ],
  "payload": "BLOB_PAYLOAD"
}

Per inviare la richiesta, espandi una delle seguenti opzioni:

Se la richiesta signBlob ha avuto esito positivo, il corpo della risposta contiene un blob firmato e l'ID della chiave di firma utilizzato per firmare il blob. Puoi utilizzare il valore signedBlob come token di connessione per autenticare direttamente una richiesta per conto dell'account di servizio. Il token è valido fino alla scadenza della chiave privata gestita dall'account di servizio. L'ID di questa chiave è il valore del campo keyId nella risposta. 

{
  "keyId": "42ba1e...fc0a",
  "signedBlob": "eyJ0eXAi...NiJ9"
}

Specifica di una catena di delega

Quando utilizzi un flusso di richiesta delegato per creare le credenziali dell'account di servizio di breve durata, il corpo della richiesta per ogni API deve specificare la catena di delega dell'account di servizio nell'ordine corretto e nel seguente formato:

projects/-/serviceAccounts/SA_ID

Sostituisci SA_ID con l'ID numerico univoco dell'account di servizio o l'indirizzo email dell'account di servizio.

Ad esempio, in una catena di delega che passa da SA_1 (chiamante) a SA_2 (delegata) a SA_3 (delegata) a SA_4, il campo delegates[] conterrà SA_2 e SA_3 nel seguente ordine:

{
  "delegates": [
    "projects/-/serviceAccounts/SA_2@PROJECT_ID.iam.gserviceaccount.com",
    "projects/-/serviceAccounts/SA_3@PROJECT_ID.iam.gserviceaccount.com"
  ]
}

Il chiamante e l'account di servizio per i quali viene creata la credenziale non sono inclusi nella catena di delega.