Concedi il ruolo Service Account User per i service account run-as

Questa pagina fa parte di Prepararsi alle imminenti modifiche all'autorizzazione. Elenca chi ha bisogno del ruolo Service Account User (roles/iam.serviceAccountUser) e mostra come concederlo.

Avviso: concedi il ruolo prima di impostare un service account Esegui come. L'impostazione di un valore significa pubblicare l'integrazione e la pubblicazione richiede questo ruolo. Se imposti prima il account di servizio, la pubblicazione che avrebbe salvato la correzione può essere rifiutata.

Chi ha bisogno del ruolo Service Account User

Le seguenti entità richiedono il ruolo Utente service account nel account di servizio elencato:

Entità	Service account
Chiunque pubblichi o testi l'integrazione, inclusa l'automazione del deployment	Il account di servizio Esegui come dell'integrazione
Chiunque esegua l'integrazione tramite l'API o la console Google Cloud , in modo sincrono o asincrono	Il account di servizio Esegui come dell'integrazione
Il account di servizio utilizzato da un trigger per avviare l'integrazione: l'email del service account di un trigger Cloud Scheduler o il service account di un trigger Cloud Pub/Sub, di un trigger Eventarc o di un trigger di eventi Integration Connectors. Non è necessario se l'account è lo stesso del service account di esecuzione.	Il account di servizio Esegui come dell'integrazione
Chiunque approvi o riprenda una corsa sospesa	Il account di servizio Esegui come dell'integrazione
Chiunque avvii un'integrazione che chiama una sottointegrazione con l'attività Chiama integrazione. Per un'integrazione avviata da un trigger con un account di servizio, questo è il account di servizio del trigger.	Il account di servizio Esegui come dell'integrazione secondaria, oltre a quello dell'integrazione chiamante
Il account di servizio Esegui come dell'integrazione chiamante, quando chiama un'integrazione secondaria in modo asincrono. Non necessario se entrambe le integrazioni utilizzano lo stesso account di serviziot.	Il account di servizio Esegui come dell'integrazione secondaria
Chiunque crei o modifichi un profilo di autenticazione di tipo Service account o Token OIDC	Il account di servizio indicato nel profilo
Chiunque pubblichi o testi un'integrazione che utilizza quel profilo	Il account di servizio indicato nel profilo
Chiunque esegua un'integrazione che raggiunge un'attività utilizzando quel profilo. Per un'esecuzione asincrona o pianificata, questo è il account di servizio di esecuzione dell'integrazione o l'agente di servizio Application Integration, [e-mail], se l'integrazione non ne ha uno. In questo caso, la soluzione migliore è impostare un account di servizio run-as.	Il account di servizio indicato nel profilo

Il salvataggio di una bozza non richiede l'utente del service account. I controlli su pubblicazione, test e salvataggio dei profili di autenticazione sono già applicati. I controlli sull'esecuzione, l'approvazione, la chiamata di sotto-integrazioni e l'esecuzione di attività che utilizzano un profilo di autenticazione diventano effettivi man mano che l'implementazione procede, quindi concedi ogni riga ora per mantenere in esecuzione le integrazioni quando lo fanno.

Nota:i ruoli di Application Integration, incluso roles/integrations.integrationInvoker, non concedono iam.serviceAccounts.actAs. L'utente account di servizio è sempre una concessione separata.

Concedi il ruolo

Per concedere il ruolo a qualcuno, esegui questo comando:

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT \
    --project=SERVICE_ACCOUNT_PROJECT_ID \
    --member='user:PRINCIPAL' \
    --role='roles/iam.serviceAccountUser'

Sostituisci quanto segue:

• SERVICE_ACCOUNT: l'indirizzo email del service account run-as o dell'account denominato in un profilo di autenticazione
• SERVICE_ACCOUNT_PROJECT_ID: l'ID del progetto che possiede il service account
• PRINCIPAL: l'indirizzo email dell'utente

Per altri tipi di principal, utilizza il prefisso --member corrispondente:

• Gruppi:utilizza group:. Ti consigliamo di utilizzare i gruppi Google anziché i singoli account utente per semplificare la gestione dell'accesso man mano che i membri del team cambiano.
• Service account: utilizza serviceAccount: per processi automatizzati, applicazioni e service account di attivazione.

Attenzione:il flag --project deve specificare il progetto proprietario del account di servizio. Se il tuo account di servizio run-as si trova in un progetto diverso dall'integrazione, la concessione deve essere effettuata nel progetto del account di servizio. La concessione nel progetto dell'integrazione non avrà alcun effetto. Questo è l'errore più comune quando si apportano queste modifiche. Funziona anche una concessione a livello di progetto, a condizione che si trovi nel progetto proprietario del service account.

Per fare lo stesso nella console Google Cloud :

1. Vai a IAM e amministrazione > Service account.
2. Seleziona il account di servizio.
3. Fai clic su Autorizzazioni > Concedi l'accesso.

Per eseguire la concessione, devi disporre dell'autorizzazione roles/iam.serviceAccountAdmin sul service account. I Project Owner ce l'hanno. Per saperne di più, vedi Gestire l'accesso ai service account.

Passaggi successivi

• Imposta un service account run-as sulle integrazioni che vengono eseguite senza una persona.
• Se una concessione non sembra funzionare, consulta la sezione Risoluzione dei problemi relativi agli errori di autorizzazione.