Creare credenziali di breve durata per più account di servizio

Questa pagina spiega come creare credenziali di breve durata per un account di servizio in base a una catena di delega di service account. Puoi utilizzare questo approccio quando devi effettuare una serie di chiamate di generazione di token per ottenere un token con le autorizzazioni necessarie per svolgere l'attività.

Dopo aver ottenuto una credenziale di breve durata, puoi utilizzarla per impersonare l'account di servizio.

Se puoi generare un token con le autorizzazioni richieste con una singola chiamata di generazione del token, devi creare credenziali di breve durata direttamente per il service account.

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 durate di poche ore o meno, e non vengono aggiornate automaticamente. 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 deaccount di serviziont.

Puoi creare i seguenti tipi di credenziali di breve durata per un service account:

  • 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 per un account di servizio, il token di accesso non include un token di aggiornamento, il che significa che quando il token scade, devi ripetere la procedura di creazione del token per generarne uno nuovo.

    Per maggiori 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 saperne di più, consulta Token ID e Autenticazione per applicazioni ospitate su Cloud Run o Cloud Run Functions.

  • Token web JSON (JWT) autofirmati

    Puoi utilizzare i JWT autofirmati per autenticarti 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, in genere a fini di autenticazione.

Flusso delle richieste delegate

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

Ogni account di servizio nella catena di delega deve disporre delle autorizzazioni richieste per il account di servizio successivo nella catena, in modo da poter inoltrare 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 service account.

Prima di iniziare

  • Enable the IAM and Service Account Credentials APIs.

    Enable the APIs

  • Informazioni sui service account IAM

  • Se non l'hai ancora fatto, abilita la fatturazione e l'API IAM seguendo i passaggi della guida rapida.

  • Identifica i service account che utilizzerai nella catena di delega.

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

Fornire le autorizzazioni richieste

Una richiesta delegata coinvolge più di due identità: il chiamante, uno o più service account in una catena di delega e infine il account di servizio per cui viene creata una credenziale. In questo flusso, considera le seguenti identità:

  • Service Account 1 (SA_1), il chiamante che invia una richiesta per le credenziali di breve durata.
  • Service account 2 (SA_2), un service account intermediario che delegherà la richiesta iniziale a SA_3. Questo account si limita a inoltrare la richiesta e non concede alcun accesso aggiuntivo a SA_1 o SA_3.
  • Service account 3 (SA_3), l'account con privilegi limitati per cui vengono create le credenziali.

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

In questo esempio specifico, a SA_1 deve essere concesso il ruolo Creatore token account di servizio (roles/iam.serviceAccountTokenCreator) su SA_2. Questo è un esempio di come l'account di servizio SA_2 viene trattato come una risorsa: quando concedi il ruolo su SA_2, aggiorni la relativa policy di autorizzazione nello stesso modo in cui aggiorneresti qualsiasi altra risorsa.

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

Successivamente, a SA_2 deve essere concesso anche il ruolo Creatore token account di servizio (roles/iam.serviceAccountTokenCreator) su SA_3. In questo modo SA_2 può creare credenziali temporanee per SA_3.

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

API

Innanzitutto, recupera la policy di autorizzazione per SA_2 (il account di servizio intermediario):

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

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

  • PROJECT_ID: il tuo ID progetto Google Cloud . Gli ID progetto sono stringhe alfanumeriche, come my-project.
  • SA_2: il nome del service account 2.
  • POLICY_VERSION: La versione della policy da restituire. Le richieste devono specificare la versione più recente delle norme, ovvero la versione 3. Per maggiori dettagli, vedi Specificare una versione delle norme quando si recuperano le norme.

Metodo HTTP e URL:

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

Corpo JSON della richiesta:

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

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

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

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

Successivamente, modifica la policy 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 del passaggio precedente, aggiungi quanto segue:

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

Poi, scrivi le norme di autorizzazione aggiornate per SA_2:

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

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

  • PROJECT_ID: il tuo ID progetto Google Cloud . Gli ID progetto sono stringhe alfanumeriche, come my-project.
  • SA_2: il nome del service account 2.
  • POLICY: una rappresentazione JSON della policy che vuoi impostare. Per ulteriori informazioni sul formato di un criterio, consulta la documentazione di riferimento sui criteri.

    Ad esempio, per impostare la norma di autorizzazione mostrata nel passaggio precedente, sostituisci POLICY con quanto segue:

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

Metodo HTTP e URL:

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

Corpo JSON della richiesta:

{
  "policy": POLICY
}

Per inviare la richiesta, espandi una di queste opzioni:

La risposta contiene la policy di autorizzazione aggiornata.

Ora recupera la policy di autorizzazione per SA_3 (il service account per cui vengono create le credenziali):

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

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

  • PROJECT_ID: il tuo ID progetto Google Cloud . Gli ID progetto sono stringhe alfanumeriche, come my-project.
  • SA_3: il nome dell'account di servizio 3.
  • POLICY_VERSION: La versione della policy da restituire. Le richieste devono specificare la versione più recente delle norme, ovvero la versione 3. Per maggiori dettagli, vedi Specificare una versione delle norme quando si recuperano le norme.

Metodo HTTP e URL:

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

Corpo JSON della richiesta:

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

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

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

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

Successivamente, modifica la policy 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 del passaggio precedente, aggiungi quanto segue:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:my-user@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 il account di servizio.

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

  • PROJECT_ID: il tuo ID progetto Google Cloud . Gli ID progetto sono stringhe alfanumeriche, come my-project.
  • SA_3: il nome dell'account di servizio 3.
  • POLICY: una rappresentazione JSON della policy che vuoi impostare. Per ulteriori informazioni sul formato di un criterio, consulta la documentazione di riferimento sui criteri.

    Ad esempio, per impostare la norma di autorizzazione mostrata nel passaggio precedente, sostituisci POLICY con quanto segue:

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

Metodo HTTP e URL:

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

Corpo JSON della richiesta:

{
  "policy": POLICY
}

Per inviare la richiesta, espandi una di queste opzioni:

La risposta contiene la policy di autorizzazione aggiornata.

Richiedere credenziali di breve durata

Dopo aver concesso i ruoli appropriati a ogni identità, puoi richiedere credenziali di breve durata per ilaccount di serviziot 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). A tale scopo, identifica gli account di servizio i cui token necessitano di una durata estesa, quindi aggiungi questi service account a un criterio dell'organizzazione che includa il vincolo dell'elenco constraints/iam.allowServiceAccountCredentialLifetimeExtension. Puoi quindi specificare una durata fino a 43.200 secondi quando crei un token per questi service account.

Per generare un token di accesso OAuth 2.0 per un account di servizio:

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, apporta le seguenti sostituzioni:

  • SA_NAME: il nome del account di servizio per cui vuoi creare un token.
  • PROJECT_ID: il tuo ID progetto Google Cloud . Gli ID progetto sono stringhe alfanumeriche, come my-project.
  • DELEGATES: se utilizzi un flusso di richieste delegate, consulta Specifica di 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: il periodo di tempo fino alla 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 il account di servizio a un criterio dell'organizzazione che includa il vincolo dell'elenco constraints/iam.allowServiceAccountCredentialLifetimeExtension.

Metodo HTTP e URL:

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

Corpo JSON della richiesta:

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

Per inviare la richiesta, espandi una di queste opzioni:

Se la richiesta generateAccessToken è andata a buon fine, il corpo della risposta contiene un token di accesso OAuth 2.0 e un tempo di scadenza. accessToken può quindi essere utilizzato per autenticare una richiesta per conto del account di servizio fino al raggiungimento di expireTime:

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

Generare token ID OpenID Connect

I token ID OpenID Connect sono validi per 1 ora (3600 secondi). Per generare un token ID per un service account:

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, apporta le seguenti sostituzioni:

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

Metodo HTTP e URL:

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

Corpo JSON della richiesta:

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

Per inviare la richiesta, espandi una di queste opzioni:

Se la richiesta generateId è andata a buon fine, il corpo della risposta contiene un token ID valido per 1 ora. Il token può quindi essere utilizzato per autenticare una richiesta per conto del account di servizio:

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

Crea un token web JSON (JWT) autofirmato

I token JWT (JSON Web Token) autofirmati sono utili in una serie di 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 o non Google, come le applicazioni App Engine. Google Cloud In questo scenario, un'applicazione può firmare un token che può essere verificato da un'altra applicazione a scopo di autenticazione.
  • Trattare un account di servizio come un provider di identità firmando un JWT che contiene rivendicazioni 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, apporta le seguenti sostituzioni:

  • SA_NAME: il nome del account di servizio per cui vuoi creare un token.
  • PROJECT_ID: il tuo ID progetto Google Cloud . Gli ID progetto sono stringhe alfanumeriche, come my-project.
  • DELEGATES: se utilizzi un flusso di richieste delegate, consulta Specifica di 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 che contiene un insieme di attestazioni JWT. Includi le rivendicazioni necessarie per il caso d'uso che ti interessa e per soddisfare i requisiti di convalida per il servizio che stai chiamando. Se chiami un'API Google, consulta la guida all'autenticazione di Google per i requisiti delle rivendicazioni.

    L'attestazione exp (ora di scadenza) non deve essere successiva di più di 12 ore. Se chiami un'API Google, l'attestazione exp deve essere impostata non più di un'ora in futuro.

    Il seguente payload di esempio contiene rivendicazioni per chiamare un'API di Google, dove EXP è un timestamp intero che rappresenta l'ora 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 HTTP e URL:

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

Corpo JSON della richiesta:

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

Per inviare la richiesta, espandi una di queste opzioni:

Se la richiesta signJwt è andata a buon fine, il corpo della risposta contiene un JWT firmato e l'ID della chiave di firma utilizzata per firmare il JWT. Puoi utilizzare il valore signedJwt come token di autenticazione per autenticare direttamente una richiesta per conto del account di servizio. Il token è valido fino all'ora di scadenza specificata nella richiesta:

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

Crea un blob autofirmato

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

Per generare un blob autofirmato per un account di servizio:

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, apporta le seguenti sostituzioni:

  • SA_NAME: il nome del account di servizio per cui vuoi creare un token.
  • PROJECT_ID: il tuo ID progetto Google Cloud . Gli ID progetto sono stringhe alfanumeriche, come my-project.
  • DELEGATES: se utilizzi un flusso di richieste delegate, consulta Specifica di 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 HTTP e URL:

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

Corpo JSON della richiesta:

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

Per inviare la richiesta, espandi una di queste opzioni:

Se la richiesta signBlob è andata a buon fine, il corpo della risposta contiene un blob firmato e l'ID della chiave di firma utilizzata per firmare il blob. Puoi utilizzare il valore signedBlob come token di autenticazione per autenticare direttamente una richiesta per conto del account di servizio. Il token è valido fino alla scadenza della chiave privata gestita dal sistema delaccount di serviziot. L'ID di questa chiave è il valore del campo keyId nella risposta.

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

Specificare una catena di delega

Quando utilizzi un flusso di richieste delegate per creare 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 delaccount di serviziot o con il suo indirizzo email.

Ad esempio, in una catena di delega che va da SA_1 (chiamante) a SA_2 (delegato) a SA_3 (delegato) a SA_4, il campo delegates[] conterrebbe 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 il account di servizio per cui vengono create le credenziali non sono inclusi nella catena di delega.