Account di servizio predefinito Cloud Build

A seconda delle impostazioni del progetto, Cloud Build potrebbe utilizzare l'account di servizio precedente di Cloud Build o l'account di servizio predefinito di Compute Engine per eseguire le build per tuo conto. L'email per l'account di servizio legacy di Cloud Build è [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com e l'email per l'account di servizio predefinito di Compute Engine è [PROJECT_NUMBER]-compute@developer.gserviceaccount.com. Gli account di servizio predefiniti potrebbero disporre di autorizzazioni inutilmente generiche per il tuo caso d'uso. Puoi migliorare la tua postura di sicurezza seguendo il principio del privilegio minimo. Nell'ambito di questo principio, consigliamo di creare il tuo account di servizio per eseguire build per conto tuo. In questo modo è possibile ridurre il potenziale impatto di configurazioni errate o utenti malintenzionati.

Questa pagina illustra tutte le autorizzazioni di cui dispone per impostazione predefinita l'account di servizio Cloud Build legacy.

Per informazioni sull'account di servizio predefinito di Compute Engine, consulta Account di servizio predefinito Compute Engine.

Per scoprire come concedere o revocare le autorizzazioni per Cloud Build account di servizio predefiniti, consulta Configura l'accesso per l'account di servizio predefinito di Cloud Build.

Autorizzazioni predefinite dell'account di servizio Cloud Build legacy

Se le impostazioni del progetto consentono l'utilizzo dell'account di servizio Cloud Build legacy, verrà concesso il ruolo Account di servizio Cloud Build per le risorse del progetto. Questo ruolo contiene un certo numero di autorizzazioni aggiuntive, come la possibilità di aggiornare le build o scrivere log. Il servizio l'account utente utilizza queste autorizzazioni solo come richiesto per eseguire azioni quando che esegue la build. Ad esempio, l'account di servizio utilizza l'autorizzazione artifactregistry.dockerimages.get per recuperare un'immagine Docker da Container Registry se la build è configurata in questo modo. Se non prevedi di eseguire un'azione durante il processo di compilazione, ti consigliamo di revocare l'autorizzazione corrispondente dall'account di servizio per rispettare il principio di sicurezza del privilegio minimo.

La tabella seguente elenca le autorizzazioni contenute nel ruolo Account di servizio Cloud Build e lo scopo per cui l'account di servizio legacy Cloud Build utilizza queste autorizzazioni.

Autorizzazione Descrizione Scopo dell'autorizzazione
cloudbuild.builds.create Può creare build e trigger Obbligatorio per:
  • Utilizza i trigger di build.
  • Crea, elenca, recupera o annulla le build.
cloudbuild.builds.update Può aggiornare le build e i trigger
cloudbuild.builds.list Può elencare build e trigger
cloudbuild.builds.get Può ottenere una build e un trigger
cloudbuild.workerpools.use Può utilizzare un pool privato Richiesta per eseguire le build in un pool privato.
logging.logEntries.create Può scrivere log Obbligatorio per creare ed elencare i log di compilazione in Cloud Logging.
logging.logEntries.list Può elencare i log
logging.views.access Può visualizzare i log
pubsub.topics.create Può creare argomenti Pub/Sub Obbligatorio per inviare gli aggiornamenti della compilazione a Pub/Sub.
pubsub.topics.publish Può pubblicare in Pub/Sub
remotebuildexecution.blobs.get Può ottenere l'accesso per approvare o rifiutare le build. Obbligatorio per approvare o rifiutare le build in attesa
resourcemanager.projects.get Può ottenere informazioni sul progetto
resourcemanager.projects.list Può elencare i progetti
source.repos.get Può leggere il codice sorgente dai repository in Cloud Source Repositories Obbligatorio per:
  • Utilizzare i trigger Bitbucket e Cloud Source Repositories.
  • Estrai il codice sorgente da Cloud Source Repositories.
source.repos.list Può elencare i repository in Cloud Source Repositories
storage.buckets.create Può creare bucket Cloud Storage Obbligatorio per:
  • Archivia e recupera le immagini in Container Registry ( Deprecato).
  • Archivia e recupera gli elementi in Cloud Storage.
  • Invia manualmente le build tramite gcloud builds submit.
  • Memorizza i log di compilazione nel bucket di log creato dall'utente.
storage.buckets.get Può ottenere 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 oggetti Cloud Storage
storage.objects.get Può leggere gli oggetti Cloud Storage
artifactregistry.repositories.uploadArtifacts Può caricare artefatti nei repository in Artifact Registry Obbligatorio per gestire gli artefatti in Artifact Registry.
artifactregistry.repositories.downloadArtifacts Può scaricare artefatti da un repository in Artifact Registry
artifactregistry.aptartifacts.create Può caricare artefatti Apt in Artifact Registry
artifactregistry.dockerimages.get Può recuperare le immagini Docker da Artifact Registry
artifactregistry.dockerimages.list Può elencare le immagini Docker archiviate in Artifact Registry
artifactregistry.kfpartifacts.create Può caricare un artefatto KFP in Artifact Registry
artifactregistry.locations.get Può ottenere informazioni su una località per una risorsa in Artifact Registry
artifactregistry.locations.list Può elencare le località supportate per Artifact Registry
artifactregistry.mavenartifacts.get Può recuperare pacchetti Maven da Artifact Registry
artifactregistry.mavenartifacts.list Può elencare i pacchetti Maven da Artifact Registry
artifactregistry.npmpackages.get Può ricevere pacchetti npm da Artifact Registry
artifactregistry.npmpackages.list Può elencare i pacchetti npm da Artifact Registry
artifactregistry.projectsettings.get Può recuperare le impostazioni del progetto da Artifact Registry
artifactregistry.pythonpackages.get Può recuperare i pacchetti Python da Artifact Registry
artifactregistry.pythonpackages.list Può elencare i pacchetti Python da Artifact Registry
artifactregistry.yumartifacts.create Può caricare gli elementi Yum in Artifact Registry
artifactregistry.repositories.createOnPush Può creare un repository gcr.io in Artifact Registry la prima volta che viene eseguito il push di un'immagine a un nome host gcr.io nel progetto.
artifactregistry.repositories.get Può ottenere un repository da Artifact Registry
artifactregistry.repositories.list Può elencare i repository in Artifact Registry
artifactregistry.repositories.listEffectiveTags Può elencare i tag per gli artefatti in Artifact Registry Necessario per gestire i tag per gli artefatti in Artifact Registry.
artifactregistry.repositories.listTagBindings Può elencare le informazioni di associazione dei tag per gli elementi in Artifact Registry
artifactregistry.tags.create Può creare tag in Artifact Registry
artifactregistry.tags.get Può ricevere tag da Artifact Registry
artifactregistry.tags.list Può elencare i tag in Artifact Registry
artifactregistry.tags.update Può aggiornare i tag in Artifact Registry
artifactregistry.versions.list Può elencare le versioni in Artifact Registry
artifactregistry.versions.get Può ottenere le versioni in Artifact Registry
containeranalysis.occurrences.create Può creare un'occorrenza di Artifact Analysis L'account di servizio Cloud Build non utilizza queste autorizzazioni, ma sono incluse per la compatibilità con le versioni precedenti.
containeranalysis.occurrences.delete Può eliminare un'occorrenza di Artifact Analysis
containeranalysis.occurrences.get Può ottenere un'occorrenza Artifact Analysis
containeranalysis.occurrences.list Può elencare le occorrenze di Artifact Analysis
containeranalysis.occurrences.update Può aggiornare le occorrenze di Artifact Analysis

Trigger di build

Quando crei trigger di build, devi scegliere l'account di servizio usato per eseguire la build. Puoi configurare ogni attivatore con un account di servizio diverso. L'unica eccezione è se nel progetto è abilitato l'account di servizio Cloud Build legacy, nel qual caso gli trigger di compilazione utilizzano per impostazione predefinita l'account di servizio legacy quando non è selezionato nessun altro account.

Accesso degli utenti agli attivatori

L'accesso degli utenti agli attivatori dipende dal tipo di account di servizio configurato per l'attivatore:

  • Account di servizio legacy di Cloud Build (se abilitato): Qualsiasi utente con il ruolo Editor Cloud Build può creare di eseguire direttamente un trigger. Ad esempio, un utente può eseguire manualmente l'attivatore. Qualsiasi utente con il ruolo Editor di Cloud Build può aggiornare un trigger, a condizione che l'trigger utilizzi l'account di servizio precedente di Cloud Build.

  • Account di servizio specificato dall'utente o account di servizio predefinito di Compute Engine: qualsiasi utente con il ruolo Editor di Cloud Build che dispone dell'autorizzazioneiam.serviceAccounts.actAs può creare ed eseguire direttamente un trigger. Ad esempio, un utente può eseguire manualmente l'attivatore. Qualsiasi utente con il ruolo Editor di Cloud Build può actualizare un trigger purché disponga delle autorizzazioni iam.serviceAccounts.actAs sia per l'account di servizio configurato in precedenza sia per il nuovo account di servizio specificato nell'trigger. Per concedere questa autorizzazione a un utente, puoi assegnare un ruolo predefinito con l'autorizzazione, ad esempio il ruolo Utente account di servizio (roles/iam.serviceAccountUser). In alternativa, puoi creare un ruolo IAM personalizzato con l'autorizzazione iam.serviceAccounts.actAs e poi assegnarlo all'utente. Per scoprire di più sulle autorizzazioni degli account di servizio, consulta Ruoli per l'autenticazione dell'account di servizio.

Privilegi dei trigger in fase di build

L'account di servizio configurato per un trigger di build può fornire autorizzazioni elevate in fase di build per gli utenti che utilizzano trigger per richiamare una build. Questo vale sia per l'account di servizio precedente sia per gli account di servizio specificati dall'utente. Tieni presente le seguenti implicazioni per la sicurezza quando utilizzi gli attivatori di compilazione:

  • Un utente senza accesso al tuo progetto Google Cloud, ma con accesso in scrittura al repository associato agli trigger di compilazione nel progetto, avrà le autorizzazioni per modificare il codice in fase di compilazione. Ad esempio, gli utenti possono invocare indirettamente un attivatore quando eseguono il push del nuovo codice sorgente in un repository collegato.

  • Se utilizzi trigger per richieste di pull GitHub, qualsiasi utente con accesso in lettura al repository può inviare una richiesta di pull, che può attivare una che includa le modifiche al codice nella richiesta di pull. Puoi disattivare questo comportamento scegliendo l'opzione Controllo dei commenti quando crei un Trigger della richiesta di pull GitHub. Se selezioni questa opzione, assicurerai che la build viene avviato solo se il proprietario di un repository o un collaboratore commenta /gcbrun. Per informazioni sull'utilizzo del Controllo dei commenti con gli attivatori GitHub, consulta Creazione di trigger GitHub.

Limitazioni

Per eseguire l'autenticazione tra servizi utilizzando un token ID, devi eseguire le build con un account di servizio specificato dall'utente. Cloud Build non è possibile usare l'account di servizio legacy per generare token ID.

Ad esempio, se utilizzi applicazioni serverless come le funzioni di Cloud Run, Cloud Run o App Engine e che vuoi richiamare per la tua applicazione da Cloud Build, richiede un account di servizio configurato con le autorizzazioni richieste per service-to-service autenticazione.

Per le istruzioni, vedi Autorizzare l'accesso da un servizio all'altro.

Passaggi successivi