Service account Cloud Build predefinito

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'indirizzo email dell'account di servizio precedente di Cloud Build è [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com e l'indirizzo email dell'account di servizio predefinito di Compute Engine è [PROJECT_NUMBER]-compute@developer.gserviceaccount.com. Gli account di servizio predefiniti potrebbero avere autorizzazioni inutilmente ampie per il tuo caso d'uso. Puoi migliorare la tua strategia di sicurezza seguendo il principio del privilegio minimo. Nell'ambito di questo principio, consigliamo di creare un tuo account di servizio per eseguire le build per tuo conto. In questo modo è possibile ridurre il potenziale impatto di configurazioni errate o di 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 di Compute Engine.

Per scoprire come concedere o revocare le autorizzazioni agli account di servizio predefinite di Cloud Build, consulta Configurare 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 una serie di autorizzazioni, ad esempio la possibilità di aggiornare le build o scrivere log. L'account servizio utilizza queste autorizzazioni solo se necessario per eseguire azioni durante l'esecuzione della build. Ad esempio, l'account di servizio utilizza l'autorizzazioneartifactregistry.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 Cloud Build legacy utilizza queste autorizzazioni.

Autorizzazione Descrizione Scopo dell'autorizzazione
cloudbuild.builds.create Può creare build e trigger Obbligatorio per:
  • Utilizza gli attivatori 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 una piscina privata Obbligatorio per eseguire 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ò recuperare le informazioni del progetto
resourcemanager.projects.list Può elencare i progetti
source.repos.get Può leggere il codice sorgente dai repository in Cloud Source Repositories Obbligatorio per:
  • Utilizza gli trigger di 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 ( Funzionalità deprecata).
  • Archivia e recupera gli elementi in Cloud Storage.
  • Invia le build manualmente 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 di 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 sulla posizione di una risorsa in Artifact Registry
artifactregistry.locations.list Può elencare le località supportate per Artifact Registry
artifactregistry.mavenartifacts.get Può recuperare i pacchetti Maven da Artifact Registry
artifactregistry.mavenartifacts.list Può elencare i pacchetti Maven da Artifact Registry
artifactregistry.npmpackages.get Può ottenere i 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 elementi in Artifact Registry Obbligatorio 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ò recuperare i 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 Analisi elementi
containeranalysis.occurrences.get Può ottenere un'occorrenza di 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 gli trigger di compilazione, devi scegliere l'account di servizio utilizzato per eseguire la compilazione. Puoi configurare ogni attivatore con un account di servizio diverso. L'unica eccezione è se nel progetto è abilitato il service account Cloud Build legacy, nel qual caso per impostazione predefinita gli trigger di compilazione utilizzano il service account 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 Cloud Build legacy (se abilitato): qualsiasi utente con il ruolo Editor di Cloud Build può creare e 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 degli account di servizio.

Privilegi dei trigger in fase di build

L'account di servizio configurato per un trigger di compilazione può fornire autorizzazioni elevate in fase di compilazione agli utenti che utilizzano gli trigger per richiamare una compilazione. 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 gli trigger per le richieste di pull di GitHub, qualsiasi utente con accesso in lettura al repository può inviare una richiesta di pull, il che può comportare l'esecuzione di una build che include modifiche al codice nella richiesta di pull. Puoi disattivare questo comportamento scegliendo l'opzione Controllo commenti quando crei un trigger per le richieste di pull di GitHub. Se selezioni questa opzione, la compilazione verrà avviata solo se un proprietario del repository o un collaboratore aggiunge un commento /gcbrun. Per informazioni sull'utilizzo del controllo dei commenti con gli trigger di GitHub, consulta Creare trigger di GitHub.

Limitazioni

Se devi autenticarti tra i servizi utilizzando un token di abilitazione, devi eseguire le tue build con un account di servizio specificato dall'utente. L'account di servizio Cloud Build legacy non può essere utilizzato per generare token ID.

Ad esempio, se utilizzi applicazioni di piattaforme serverless come Cloud Run Functions, Cloud Run o App Engine e vuoi invocare la tua applicazione da Cloud Build, è necessario un account di servizio specificato dall'utente configurato con le autorizzazioni richieste per l'autenticazione servizio-a-servizio.

Per le istruzioni, vedi Autorizzare l'accesso tra servizi.

Passaggi successivi