Questa pagina spiega come creare credenziali di breve durata per un account di servizio basate su una catena di delega di account di servizio. Puoi utilizzare questo approccio quando devi emettere una serie di chiamate di generazione di token per ottenere un token con le autorizzazioni necessarie per svolgere la tua attività.
Dopo aver ottenuto una credenziale di breve durata, puoi utilizzarla per simulare l'identità dell'account di servizio.
Se puoi generare un token con le autorizzazioni richieste con una singola chiamata di generazione di token, devi creare direttamente le credenziali di breve durata per l'account di servizio.
Informazioni sulla creazione di credenziali di breve durata
A seconda del tipo di token creato, puoi utilizzare le 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 dell'account di servizio di breve durata sono utili per gli scenari in cui è necessario 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.
Per un account di servizio, puoi creare i seguenti tipi di credenziali di breve durata:
Token di accesso OAuth 2.0
La maggior parte delle API Google accetta i token di accesso per l'autenticazione. Quando generi un token di accesso per un account di servizio, il token di accesso viene fornito senza un token di aggiornamento, il che significa che quando il token scade, devi repetire la procedura di creazione del token per generarne uno nuovo.
Per ulteriori informazioni, vedi Token di accesso.
Token ID OpenID Connect (OIDC)
I token ID rispettano la specifica OpenID Connect (OIDC). I token ID sono accettati da un numero limitato di servizi e applicazioni.
Per ulteriori informazioni, consulta Token ID e Autenticazione per le applicazioni ospitate su Cloud Run o Cloud Run Functions.
Token web JSON (JWT) autofirmati
Puoi utilizzare JWT autofirmati per autenticarti ad alcune API Google senza dover recuperare un token di accesso dal server di autorizzazione. Le API di cui è stato eseguito il deployment con API Gateway li richiedono.
Blob binari autofirmati
I blob con firma autografa sono utili negli scenari in cui è necessario trasmettere in modo sicuro dati binari arbitrari, in genere a fini di autenticazione.
Flusso di richieste delegate
Il flusso di richieste delegate ti 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 per l'account di servizio successivo nella catena, in modo da poter inoltrare la richiesta.
Se un account di servizio fornisce tutte le autorizzazioni di cui hai bisogno, devi utilizzare il flusso più semplice descritto in Creare credenziali di breve durata da un account di servizio.
Prima di iniziare
Enable the IAM and Service Account Credentials APIs.
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 introduttiva.
Identifica gli account di servizio che utilizzerai nella catena di delega.
Puoi creare un nuovo account di servizio e includerlo nella catena di delega, se necessario.
Fornire le autorizzazioni richieste
Una richiesta delegata coinvolge più di due identità: l'utente chiamante, uno o più account di servizio in una catena di delega e infine l'account di servizio per cui viene creata una credenziale. In questo flusso, considera le seguenti identità:
- Account di servizio 1 (
SA_1
), l'utente che effettua una richiesta per le credenziali di breve durata. - Account di servizio 2 (
SA_2
), un account di servizio intermediario che delegherà la richiesta iniziale aSA_3
. Questo account inoltra solo la richiesta, non concede alcun accesso aggiuntivo aSA_1
oSA_3
. - Service account 3 (
SA_3
), l'account con privilegi limitati per cui viene creata la credenziale.
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 account di servizio SA_2
trattato come risorsa: quando concedi il ruolo a SA_2
, aggiorni il relativo criterio di autorizzazione come faresti con qualsiasi altra risorsa.
In questo flusso di esempio è presente un solo account di servizio intermedio. Per delegare l'accesso tramite più di un account di servizio, devi anche assegnare questo ruolo a qualsiasi altro account di servizio della 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 di breve durata per SA_3
.
I passaggi che seguono utilizzano l'API REST per concedere i ruoli. Tuttavia, puoi anche utilizzare la console Google Cloud o gcloud CLI.
API
Innanzitutto, ottieni il criterio di autorizzazione per SA_2
(l'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
: l'ID del tuo progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, ad esempiomy-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 dei criteri, ovvero la versione 3. Per maggiori dettagli, consulta la sezione Specificare una versione delle norme al momento dell'ottenimento delle 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 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_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" ] } ] }
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 i dati della richiesta, apporta le seguenti sostituzioni:
PROJECT_ID
: l'ID del tuo progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, ad esempiomy-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 pagina Riferimento ai criteri.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: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 il criterio di autorizzazione aggiornato.
Ora ottieni il criterio di autorizzazione per SA_3
(l'account di servizio per cui è stata creata la credenziale):
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
: l'ID del tuo progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, ad esempiomy-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 dei criteri, ovvero la versione 3. Per maggiori dettagli, consulta la sezione Specificare una versione delle norme al momento dell'ottenimento delle 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 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 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 l'account di servizio.
Prima di utilizzare i dati della richiesta, apporta le seguenti sostituzioni:
PROJECT_ID
: l'ID del tuo progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, ad esempiomy-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 pagina Riferimento ai criteri.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: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 il criterio di autorizzazione aggiornato.
Richiedi 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:
- Token di accesso OAuth 2.0
- Token ID OpenID Connect
- Token web JSON (JWT) autofirmati
- Oggetti binari (blob) con firma autografata
Per capire come specificare una catena di delega per queste richieste, consulta la sezione Specificare una catena di delega in questa pagina.
Genera un token di accesso OAuth 2.0
Per impostazione predefinita, i token di accesso OAuth 2.0 sono validi per un massimo di un'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 account di servizio 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
account di servizio.
Per generare un token di accesso OAuth 2.0 per un account di servizio, segui questi passaggi:
API
Il metodo serviceAccounts.generateAccessToken
dell'API Credenziali account di servizio 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 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 esempiomy-project
.DELEGATES
: se utilizzi un flusso di richieste delegate, consulta Specificare una catena di delega in questa pagina. Se utilizzi un flusso di richieste dirette senza delega, ometti il campodelegates
nel corpo della richiesta.-
LIFETIME
: il tempo che rimane 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 l'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 una data di scadenza. Il token accessToken
può quindi essere utilizzato per autenticare una richiesta per conto dell'account di servizio fino a quando non viene raggiunto il token expireTime
:
{ "accessToken": "eyJ0eXAi...NiJ9", "expireTime": "2020-04-07T15:01:23.045123456Z" }
Genera token ID OpenID Connect
I token ID OpenID Connect sono validi per un'ora (3600 secondi). Per generare un token ID per un account di servizio:
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 dell'account di servizio con privilegi per cui viene creato il token di breve durata. -
AUDIENCE_NAME
: il segmento di pubblico del token, in genere l'URL dell'applicazione o del servizio a cui verrà utilizzato il token 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. token
può quindi essere utilizzato per autenticare una richiesta per conto dell'account di servizio:
{ "token": "eyJ0eXAi...NiJ9" }
Creare un token JWT (JSON Web Token) autofirmato
I token web JSON (JWT) autofirmati sono utili in una serie di scenari, ad esempio:
- Autenticazione di una chiamata a un'API Google come descritto nella Guida all'autenticazione di Google.
- Comunicazione sicura tra servizi Google Cloud o non Google, come le applicazioni App Engine. 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 claim arbitrari su un utente, un account o un dispositivo.
Per generare un token JWT autofirmato per un account di servizio:
API
Il metodo
serviceAccounts.signJwt
dell'API Credenziali account di servizio 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 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 esempiomy-project
.DELEGATES
: se utilizzi un flusso di richieste delegate, consulta Specificare una catena di delega in questa pagina. Se utilizzi un flusso di richieste dirette senza delega, ometti il campodelegates
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 tuo caso d'uso e per soddisfare i requisiti di convalida del servizio che stai chiamando. Se chiami un'API Google, consulta la Guida all'autenticazione di Google per i requisiti per la rivendicazione.La rivendicazione
exp
(ora di scadenza) non deve essere successiva di più di 12 ore. Se chiami un'API Google, il claimexp
deve essere impostato non più di 1 ora in futuro.Il seguente payload di esempio contiene rivendicazioni per chiamare un'API Google, dove
EXP
è un timestamp intero che rappresenta la data e 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 chiave di firma utilizzato per firmare il JWT. Puoi utilizzare il valore signedJwt
come
token di trasporto per autenticare direttamente una richiesta per conto dell'account di servizio. Il token è valido fino all'ora di scadenza specificata nella richiesta:
{ "keyId": "42ba1e...fc0a", "signedJwt": "eyJ0eXAi...NiJ9" }
Creare un blob autofirmato
I blob con firma autografa sono utili negli scenari in cui devi trasmettere in modo sicuro dati binari arbitrari, in genere a fini di autenticazione. Ad esempio, se vuoi utilizzare un tipo di protocollo/token personalizzato (non JWT), puoi includere questi dati in un blob firmato per l'utilizzo da parte di un servizio a valle.
Per generare un blob autofirmato per un account di servizio:
API
Il metodo serviceAccounts.signBlob
dell'API Credentials for Service Account 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 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 esempiomy-project
.DELEGATES
: se utilizzi un flusso di richieste delegate, consulta Specificare una catena di delega in questa pagina. Se utilizzi un flusso di richieste dirette senza delega, ometti il campodelegates
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 chiave di firma utilizzato per firmare il blob. Puoi utilizzare il valore signedBlob
come token di accesso 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 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 o con l'indirizzo email dell'account di servizio.
Ad esempio, in una catena di delega che va da SA_1
(chiama) a SA_2
(delegata) a SA_3
(delegata) a SA_4
, il campo delegates[]
conterrà SA_2
e SA_3
nell'ordine seguente:
{ "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 cui viene creata la credenziale non sono inclusi nella catena di delega.