Creazione di credenziali per account di servizio di breve durata

Questa pagina spiega come creare credenziali di breve durata per gli account di servizio che consentono di impersonare le proprie identità.

Gli account di servizio possono utilizzare credenziali di breve durata per autenticare le chiamate alle API Google Cloud e ad altre API non Google. Le credenziali di breve durata hanno una durata limitata, con durate di poche ore o più brevi. Le credenziali dell'account di servizio di breve durata sono utili per gli scenari in cui devi concedere un accesso limitato alle risorse agli account di servizio attendibili. Inoltre, costituiscono un rischio inferiore rispetto alle credenziali di lunga durata, come le chiavi degli account di servizio.

I tipi di credenziali supportati includono token di accesso OAuth 2.0, token ID OpenID OpenID, token web JSON (JWT) autofirmati e oggetti binari autofirmati (blob). I tipi di credenziali più utilizzati sono i token di accesso OAuth 2.0 e i token ID OIDC Connect. Di seguito sono riportati alcuni scenari di esempio:

  • Token di accesso OAuth 2.0: un token di accesso OAuth 2.0 è utile per autenticare l'accesso da un account di servizio alle API di Google Cloud. Considera il seguente caso d'uso di esempio: per ottenere autorizzazioni elevate su un progetto, un amministratore di servizio può impersonare un account di servizio per chiamare le API di Google Cloud creando un token di accesso OAuth 2.0 appartenente a tale account di servizio. La durata del token è breve e le autorizzazioni elevate sono temporanee. L'utilizzo di token di breve durata consente di implementare il principio del privilegio minimo per le identità e le risorse. Può essere utile anche quando si verifica un'emergenza in un ambiente di produzione e un amministratore di servizio ha bisogno di un'autorizzazione elevata e a breve termine per il debug.

  • Token ID OIDC: un token ID OIDC è utile per autenticare l'identità di un account di servizio per i servizi che accettano OpenID Connect. Esamina il seguente caso d'uso di esempio: creando un token ID OIDC appartenente a un account di servizio, un servizio in esecuzione su Google Cloud può autenticarsi a un altro servizio implementato su un cloud provider di terze parti, ad esempio un job di pipeline di dati. Se il servizio di destinazione è configurato con OIDC, l'autenticazione avrà esito positivo.

Prima di iniziare

  • Enable the IAM and Service Account Credentials APIs.

    Enable the APIs

  • Informazioni sugli account di servizio IAM

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

Creazione di un account di servizio

Per iniziare, crea un nuovo account di servizio.

Fornire le autorizzazioni richieste

Esistono due diversi flussi che consentono a un chiamante di creare credenziali di breve durata per un account di servizio. Ogni flusso richiede le autorizzazioni appropriate:

  • Richiesta diretta: il chiamante viene autenticato come Account Google o come account di servizio e invia una richiesta diretta per la creazione di credenziali di breve durata. In questo flusso sono coinvolte due identità: il chiamante e l'account di servizio per il quale vengono create le credenziali.

  • Richiesta delegata: come per il flusso di richieste dirette, il chiamante viene autenticato come Account Google o come account di servizio, ma la richiesta è delegata a uno o più account di servizio in una catena di delega. In questo flusso, più account di servizio agiscono come intermediari tra il chiamante originale e l'account di servizio per il quale vengono create le credenziali. Ogni account di servizio nella catena di delega deve avere le autorizzazioni richieste per trasmettere la richiesta.

    Questo flusso è utile per gli scenari in cui un progetto contiene livelli di account di servizio con privilegi limitati, ognuno dei quali è stato configurato per eseguire una funzione specifica o limitata su determinate risorse. Ad esempio, un account di servizio dispone solo delle autorizzazioni per le risorse Cloud Storage, un altro solo le autorizzazioni per le risorse di Compute Engine e così via. Per delegare correttamente la richiesta tra gli account di servizio, ogni richiesta deve essere elencata nella catena di delega.

Autorizzazioni per richieste dirette

Come descritto in Fornire le autorizzazioni richieste in questa pagina, una richiesta diretta riguarda solo due identità: il chiamante e l'account di servizio per il quale vengono create le credenziali. In questo flusso, considera le seguenti identità:

  • Account di servizio 1 (SA_1), il chiamante che invia una richiesta per le credenziali di breve durata.
  • Account di servizio 2 (SA_2), l'account con privilegi limitati per il quale vengono create le credenziali.

Per concedere a SA_1 le autorizzazioni per creare credenziali di breve durata, assegna il ruolo Creatore token account di servizio (roles/iam.serviceAccountTokenCreator) su SA_2. Questo è un esempio dell'account di servizio SA_2 che viene considerato una risorsa: quando concedi il ruolo su SA_2, aggiorni il criterio di autorizzazione nello stesso modo in cui aggiorni qualsiasi altra risorsa.

I passaggi seguenti utilizzano l'API REST per concedere il ruolo. Tuttavia, puoi anche utilizzare Cloud Console o l'interfaccia a riga di comando gcloud.

API

Per prima cosa, leggi il criterio di autorizzazione per SA_2:

Il serviceAccounts.getIamPolicy metodo ottiene un criterio di autorizzazione dell'account di servizio.

Prima di utilizzare uno qualsiasi dei dati della richiesta, effettua le seguenti sostituzioni:

  • PROJECT_ID: ID progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, come my-project.
  • SA_2: il nome dell'account di servizio 2.
  • POLICY_VERSION: la versione del criterio da restituire. Le richieste devono specificare la versione più recente del criterio, ossia la versione 3. Per informazioni dettagliate, vedi Specificare la versione di un criterio quando si riceve un criterio.

Metodo HTTP e URL: 

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 assegnato un ruolo all'account di servizio, la risposta contiene solo un valore etag. Includi il valore etag nel passaggio successivo.

Successivamente, 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 del 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"
      ]
    }
  ]
}

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 uno qualsiasi dei dati della richiesta, effettua le seguenti sostituzioni:

  • PROJECT_ID: ID progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, come 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 una norma, consulta il riferimento sulle norme.

    Ad esempio, per impostare il criterio di autorizzazione mostrato nel passaggio precedente, sostituisci POLICY con 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"
      ]
    }
  ]
}

Metodo HTTP e URL: 

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.

Autorizzazioni relative alla richiesta delegata

Come descritto nella sezione Concedere le autorizzazioni richieste in questa pagina, una richiesta delegata coinvolge 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 per le credenziali di breve durata.
  • Account di servizio 2 (SA_2), un account di servizio intermedio che delegherà la richiesta iniziale a SA_3.
  • Account di servizio 3 (SA_3), l'account con privilegi limitati per il quale 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 nella catena.

In questo particolare esempio, a SA_1 deve essere concesso il ruolo Creatore token account di servizio (roles/iam.serviceAccountTokenCreator) il giorno SA_2. Questo è un esempio dell'account di servizio SA_2 considerato come risorsa: quando concedi il ruolo su SA_2, aggiorni il relativo criterio di autorizzazione nello stesso modo in cui aggiorni qualsiasi altra risorsa.

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

Inoltre, a SA_2 deve essere concesso il ruolo Creatore token account di servizio (roles/iam.serviceAccountTokenCreator) anche 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 Cloud Console 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 serviceAccounts.getIamPolicy metodo ottiene un criterio di autorizzazione dell'account di servizio.

Prima di utilizzare uno qualsiasi dei dati della richiesta, effettua le seguenti sostituzioni:

  • PROJECT_ID: ID progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, come my-project.
  • SA_2: il nome dell'account di servizio 2.
  • POLICY_VERSION: la versione del criterio da restituire. Le richieste devono specificare la versione più recente del criterio, ossia la versione 3. Per informazioni dettagliate, vedi Specificare la versione di un criterio quando si riceve un criterio.

Metodo HTTP e URL: 

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.

Successivamente, 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 del 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"
      ]
    }
  ]
}

Quindi, 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 uno qualsiasi dei dati della richiesta, effettua le seguenti sostituzioni:

  • PROJECT_ID: ID progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, come 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 una norma, consulta il riferimento sulle norme.

    Ad esempio, per impostare il criterio di autorizzazione mostrato nel passaggio precedente, sostituisci POLICY con 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"
      ]
    }
  ]
}

Metodo HTTP e URL: 

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 serviceAccounts.getIamPolicy metodo ottiene un criterio di autorizzazione dell'account di servizio.

Prima di utilizzare uno qualsiasi dei dati della richiesta, effettua le seguenti sostituzioni:

  • PROJECT_ID: 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 del criterio da restituire. Le richieste devono specificare la versione più recente del criterio, ossia la versione 3. Per informazioni dettagliate, vedi Specificare la versione di un criterio quando si riceve un criterio.

Metodo HTTP e URL: 

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.

Successivamente, 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 del 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 uno qualsiasi dei dati della richiesta, effettua le seguenti sostituzioni:

  • PROJECT_ID: 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 del criterio che vuoi impostare. Per ulteriori informazioni sul formato di una norma, consulta il riferimento sulle norme.

    Ad esempio, per impostare il criterio di autorizzazione mostrato nel passaggio precedente, sostituisci POLICY con 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"
      ]
    }
  ]
}

Metodo HTTP e URL: 

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 ciascuna identità, puoi richiedere le 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.

Generazione di 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, per questi token puoi estendere la durata massima a 12 ore (43.200 secondi). Per farlo, identifica gli account di servizio che richiedono 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 massima di 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 uno qualsiasi dei dati della richiesta, effettua le seguenti sostituzioni:

  • SA_NAME: il nome dell'account di servizio per cui vuoi creare un token.
  • PROJECT_ID: ID progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, come my-project.
  • DELEGATES: se utilizzi un flusso di richiesta delegato, consulta 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: il periodo di tempo, in secondi, fino alla scadenza del token di accesso. 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 HTTP e URL: 

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. Il tag accessToken può quindi essere utilizzato per autenticare una richiesta per conto dell'account di servizio fino al raggiungimento del valore expireTime: 

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

Generazione dei 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, segui questi passaggi:

API

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

Prima di utilizzare uno qualsiasi dei dati della richiesta, effettua le seguenti sostituzioni:

  • SA_NAME: il nome dell'account di servizio per cui vuoi creare un token.
  • PROJECT_ID: ID progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, come my-project.
  • AUDIENCE_NAME: pubblico per il token, in genere l'URL dell'applicazione o del servizio a cui il token verrà utilizzato.

Metodo HTTP e URL: 

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com: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. Il 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 JWT (AutoSigned JSON Web Token) sono utili in diversi scenari, ad esempio:

  • Autenticazione di una chiamata a un'API di Google come descritto nella Guida all'autenticazione di Google.
  • Comunica in modo sicuro tra Google Cloud o servizi non Google, come le applicazioni App Engine. In questo scenario, un'applicazione può firmare un token che può essere verificato da un'altra applicazione per scopi di 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 una chiave privata gestita dal sistema di un account di servizio.

Prima di utilizzare uno qualsiasi dei dati della richiesta, effettua le seguenti sostituzioni:

  • SA_NAME: il nome dell'account di servizio per cui vuoi creare un token.
  • PROJECT_ID: ID progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, come my-project.
  • DELEGATES: se utilizzi un flusso di richiesta delegato, consulta 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, che è un oggetto JSON che contiene un set di attestazioni JWT. Includi le rivendicazioni necessarie per il caso d'uso desiderato e per soddisfare i requisiti di convalida per il servizio che stai chiamando. Se chiami un'API di Google, consulta la Guida all'autenticazione di Google per i requisiti della dichiarazione.

    La dichiarazione exp (ora di scadenza) non deve essere successiva a più di 12 ore nel futuro. Se chiami un'API di Google, la dichiarazione exp non deve essere impostata su più di un'ora in futuro.

    Il seguente payload di esempio contiene affermazioni 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 HTTP e URL: 

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 è necessario trasmettere in modo sicuro dati binari arbitrari, in genere per scopi di autenticazione. Ad esempio, se vuoi utilizzare un protocollo/token personalizzato (non JWT) personalizzato, puoi includere tali dati in un blob firmato per essere utilizzati da un servizio downstream.

Per generare un blob autofirmato per un account di servizio, procedi come segue:

API

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

Prima di utilizzare uno qualsiasi dei dati della richiesta, effettua le seguenti sostituzioni:

  • SA_NAME: il nome dell'account di servizio per cui vuoi creare un token.
  • PROJECT_ID: ID progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, come my-project.
  • DELEGATES: se utilizzi un flusso di richiesta delegato, consulta 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 con codifica 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 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 dal sistema dell'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 con l'indirizzo email dell'account di servizio.

Ad esempio, in una catena di delega che passa da SA_1 (caller) a SA_2 (delegato) a SA_3 (delegato) 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 vengono create le credenziali non sono inclusi nella catena di delega.