Cloud Build utilizza un account di servizio speciale per eseguire le build per tuo conto. L'email per l'account di servizio Cloud Build è [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com
. Per impostazione predefinita, l'account di servizio Cloud Build è autorizzato a eseguire diverse attività come il recupero del codice dal Cloud Source Repositories del tuo progetto o dalla scrittura di oggetti in qualsiasi bucket Cloud Storage di proprietà del tuo progetto. Anziché utilizzare l'account di servizio Cloud Build predefinito, puoi specificare il tuo account di servizio per eseguire le build per tuo conto.
Questa pagina illustra tutte le autorizzazioni dell'account di servizio Cloud Build per impostazione predefinita. Per informazioni su come concedere o revocare le autorizzazioni per l'account di servizio Cloud Build, consulta Configurazione dell'accesso per l'account di servizio Cloud Build.
Autorizzazioni predefinite dell'account di servizio Cloud Build
Quando abiliti l'API Cloud Build per un progetto Cloud, l'account di servizio Cloud Build viene creato automaticamente nel progetto e riceve il ruolo Account di servizio Cloud Build per le risorse nel progetto. Questo ruolo contiene una serie di autorizzazioni, ad esempio la possibilità
di aggiornare le build o scrivere i log. L'account di servizio utilizza queste autorizzazioni solo come richiesto per eseguire azioni durante l'esecuzione della build. Ad esempio, l'account di servizio utilizza l'autorizzazione source.repos.get
per recuperare il codice da Cloud Source Repositories se il codice sorgente della build è in Cloud Source Repositories. Se non intendi eseguire un'azione durante la procedura di compilazione, ti consigliamo di revocare l'autorizzazione corrispondente all'account di servizio Cloud Build in modo da rispettare il principio di sicurezza del privilegio minimo.
La tabella seguente elenca le autorizzazioni contenute nel ruolo dell'account di servizio Cloud Build e lo scopo per cui l'account di servizio Cloud Build utilizza le autorizzazioni.
Autorizzazione | Descrizione | Finalità dell'autorizzazione |
---|---|---|
cloudbuild.builds.create |
Può creare build e trigger | Obbligatorio per:
|
cloudbuild.builds.update |
Può aggiornare build e trigger | |
cloudbuild.builds.list |
Può elencare build e trigger | |
cloudbuild.builds.get |
Può recuperare una build e un trigger | |
storage.buckets.create |
Può creare bucket Cloud Storage | Obbligatorio per:
|
storage.buckets.get |
Può recuperare bucket Cloud Storage | |
storage.buckets.list |
Può elencare i bucket Cloud Storage | |
storage.objects.list |
Può elencare gli oggetti Cloud Storage | |
storage.objects.update |
Può aggiornare gli oggetti Cloud Storage | |
storage.objects.create |
Può scrivere oggetti Cloud Storage | |
storage.objects.delete |
Può eliminare gli oggetti Cloud Storage | |
storage.objects.get |
Può leggere oggetti Cloud Storage | |
artifactregistry.repositories.uploadArtifacts |
Può caricare gli artefatti nei repository in Artifact Registry | Obbligatorio per caricare e ricevere gli artefatti in Artifact Registry. |
artifactregistry.repositories.list |
Può elencare i repository in Artifact Registry | |
artifactregistry.repositories.get |
Può recuperare un repository da Artifact Registry | |
artifactregistry.repositories.downloadArtifacts |
Può scaricare gli artefatti da un repository in Artifact Registry | |
artifactregistry.files.list |
Può elencare i file in Artifact Registry | |
artifactregistry.files.get |
Può recuperare file da Artifact Registry | |
artifactregistry.packages.list |
Può elencare i pacchetti in Artifact Registry | |
artifactregistry.packages.get |
Può recuperare i pacchetti da Artifact Registry | |
artifactregistry.tags.create |
Può creare tag in Artifact Registry | |
artifactregistry.tags.update |
Può aggiornare i tag in Artifact Registry | |
artifactregistry.tags.list |
Può elencare i tag in Artifact Registry | |
artifactregistry.tags.get |
Può recuperare tag da Artifact Registry | |
artifactregistry.versions.list |
Può elencare le versioni in Artifact Registry | |
artifactregistry.versions.get |
Può recuperare versioni in Artifact Registry | |
logging.logEntries.create |
Può scrivere log | necessaria per creare i log di build in Cloud Logging. |
pubsub.topics.create |
Può creare argomenti Pub/Sub | Obbligatorio per eseguire il push degli aggiornamenti della build a Pub/Sub. |
pubsub.topics.publish |
Può pubblicare su Pub/Sub | |
resourcemanager.projects.get |
Può recuperare le informazioni sul progetto | Obbligatorio per recuperare le informazioni sui progetti ed elencare i progetti. |
resourcemanager.projects.list |
Può elencare i progetti | |
containeranalysis.occurrences.create |
Può creare un'occorrenza di Container Analysis | L'account di servizio Cloud Build non utilizza queste autorizzazioni, che però sono incluse per la compatibilità con le versioni precedenti. |
containeranalysis.occurrences.delete |
Può eliminare un'occorrenza di Container Analysis | |
containeranalysis.occurrences.get |
Può acquisire un'occorrenza di Container Analysis | |
containeranalysis.occurrences.list |
Può elencare le occorrenze di Container Analysis | |
containeranalysis.occurrences.update |
Può aggiornare le occorrenze di Container Analysis | |
source.repos.get |
Può leggere il codice sorgente dai repository in Cloud Source Repositories | Obbligatorio per:
|
source.repos.list |
Può elencare i repository in Cloud Source Repositories |
Trigger di build
Per impostazione predefinita, i trigger di build utilizzano l'account di servizio Cloud Build per eseguire le build. In alternativa, puoi configurare i trigger di build per eseguire le build con un account di servizio a tua scelta. Puoi configurare ogni trigger con un account di servizio diverso.
Tieni presente le seguenti considerazioni quando scegli l'account di servizio da specificare per un trigger di build:
Account di servizio Cloud Build predefinito: qualsiasi utente con il ruolo Editor Cloud Build può creare ed eseguire direttamente un trigger. Ad esempio, un utente può eseguire l'attivatore manualmente. Qualsiasi utente può anche eseguire indirettamente un trigger. Ad esempio, un utente può richiamare indirettamente un trigger quando invia il nuovo codice sorgente a un repository connesso. Qualsiasi utente con il ruolo Cloud Build Editor può aggiornare un trigger purché l'account di servizio precedente e il nuovo account di servizio specificato nel trigger siano account Cloud Build predefinito.
Account di servizio specificato dall'utente: qualsiasi utente con il ruolo Editor Cloud Build che dispone delle autorizzazioni di rappresentazione per l'account di servizio (
iam.serviceAccount.actAs
) può creare ed eseguire direttamente un trigger. Ad esempio, un utente può eseguire manualmente l'attivatore. Qualsiasi utente può anche eseguire indirettamente un trigger. Ad esempio, un utente può richiamare indirettamente un trigger quando esegue il push di nuove origini a un repository connesso. Tutti gli utenti con il ruolo Cloud Build Editor possono aggiornare un trigger purché dispongano delle autorizzazioni di rappresentazione sia per l'account di servizio configurato in precedenza che per il nuovo account di servizio specificato nel trigger. Puoi creare un ruolo IAM personalizzato con un'autorizzazione di rappresentazione o utilizzare ruoli predefiniti che consentono alle entità di impersonare un account di servizio. Per ulteriori informazioni sulle autorizzazioni di rappresentazione, consulta Gestione dell'impersonificazione degli account di servizio.
Inoltre, l'account di servizio predefinito di Cloud Build e gli account di servizio specificati dall'utente possono fornire autorizzazioni di tempo di build elevate agli utenti che utilizzano trigger per richiamare una build. Tieni presente le seguenti implicazioni sulla sicurezza quando utilizzi trigger di build associati all'account di servizio Cloud Build predefinito:
- Un utente che non ha accesso al tuo progetto Cloud, ma con accesso in scrittura al repository associato ai trigger di build nel progetto, avrà le autorizzazioni per modificare il codice in fase di creazione.
- Se utilizzi i trigger di richiesta di pull di GitHub, qualsiasi utente con accesso in lettura al repository può inviare una richiesta di pull, che può attivare una build che include modifiche al codice nella richiesta di pull. Puoi disattivare
questo comportamento scegliendo l'opzione Controllo commenti durante la creazione di un
attivatore di richiesta pull di GitHub. Se selezioni questa opzione, verrà avviata la build
solo se un proprietario del repository o un collaboratore commenta
/gcbrun
. Per informazioni sull'utilizzo del controllo commenti con i attivatori GitHub, consulta Creazione di trigger GitHub.
Passaggi successivi
- Scopri di più sugli account di servizio specificati dall'utente.
- Scopri di più sulla configurazione dell'accesso per l'account di servizio Cloud Build.
- Scopri di più sulla configurazione dell'accesso alle risorse Cloud Build.
- Scopri le autorizzazioni necessarie per visualizzare i log di build.