Account di servizio Cloud Build

Cloud Build può utilizzare un account di servizio speciale per eseguire le build per tuo conto. L'indirizzo email per l'account di servizio Cloud Build è [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com. Questo account di servizio potrebbe avere autorizzazioni inutilmente ampie per il tuo caso d'uso. Puoi migliorare la strategia di sicurezza seguendo il principio del privilegio minimo. Secondo questo principio, ti consigliamo di creare un tuo account di servizio affinché le build vengano eseguite per tuo conto, in modo da ridurre il potenziale impatto di configurazioni errate o di utenti malintenzionati.

Questa pagina illustra tutte le autorizzazioni di cui dispone l'account di servizio Cloud Build per impostazione predefinita. Per informazioni su come concedere o revocare le autorizzazioni all'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 Google Cloud, l'account di servizio Cloud Build viene creato automaticamente nel progetto e gli viene assegnato il ruolo Account di servizio Cloud Build per le risorse nel progetto. Questo ruolo contiene una serie di autorizzazioni, come la possibilità di aggiornare build o scrivere log. L'account di servizio utilizza queste autorizzazioni solo come necessario 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 si trova in Cloud Source Repositories. Se non prevedi di eseguire un'azione nell'ambito del processo di compilazione, ti consigliamo di revocare l'autorizzazione corrispondente dall'account di servizio Cloud Build per rispettare il principio di sicurezza del privilegio minimo.

Nella tabella seguente sono elencate le autorizzazioni incluse nel ruolo dell'account di servizio Cloud Build e lo scopo per cui l'account di servizio Cloud Build le utilizza.

Autorizzazione Description Scopo dell'autorizzazione
cloudbuild.builds.create Può creare build e trigger Obbligatorio per:
  • Utilizza i trigger di build.
  • Creare, elencare, recuperare o annullare le build.
cloudbuild.builds.update Può aggiornare build e trigger
cloudbuild.builds.list Può elencare build e trigger
cloudbuild.builds.get Può ottenere una build e un trigger
cloudbuild.workerpools.use Può usare un pool privato Necessario per eseguire build in un pool privato.
logging.logEntries.create Può scrivere log Necessario per creare ed elencare i log di build 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 Necessario per eseguire il push degli aggiornamenti delle build a Pub/Sub.
pubsub.topics.publish Può pubblicare su 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 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 di Bitbucket e Cloud Source Repositories.
  • Esegui il pull del 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 immagini in Container Registry ( deprecata).
  • Archivia e recupera artefatti in Cloud Storage.
  • Invia manualmente le build tramite gcloud builds submit.
  • Archivia i log di build nel bucket di log creato dall'utente.
storage.buckets.get Può recuperare bucket Cloud Storage
storage.buckets.list Può elencare i bucket Cloud Storage
storage.objects.list Può elencare gli oggetti di Cloud Storage
storage.objects.update Può aggiornare gli oggetti di Cloud Storage
storage.objects.create Può scrivere oggetti Cloud Storage
storage.objects.delete Può eliminare gli oggetti di Cloud Storage
storage.objects.get Può leggere gli oggetti di 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 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ò recuperare pacchetti npm da Artifact Registry
artifactregistry.npmpackages.list Può elencare i pacchetti npm da Artifact Registry
artifactregistry.projectsettings.get Può recuperare le impostazioni di progetto da Artifact Registry
artifactregistry.pythonpackages.get Può recuperare pacchetti Python da Artifact Registry
artifactregistry.pythonpackages.list Può elencare i pacchetti Python da Artifact Registry
artifactregistry.yumartifacts.create Può caricare artefatti Yum su 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ò recuperare 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 sull'associazione di tag per gli artefatti in Artifact Registry
artifactregistry.tags.create Può creare tag in Artifact Registry
artifactregistry.tags.get Può recuperare 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ò recuperare versioni in Artifact Registry
containeranalysis.occurrences.create Può creare un'occorrenza 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ò recuperare 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

Per impostazione predefinita, i trigger di build utilizzano l'account di servizio Cloud Build per eseguire le build. In alternativa, puoi configurare trigger di build per l'esecuzione delle build con un account di servizio a tua scelta. Puoi configurare ogni trigger con un account di servizio diverso.

Quando scegli l'account di servizio da specificare per un trigger di build, tieni presente quanto segue:

  • Account di servizio Cloud Build predefinito: qualsiasi utente con il ruolo Editor di Cloud Build può creare ed eseguire direttamente un trigger. Ad esempio, un utente può eseguire il trigger manualmente. Qualsiasi utente può anche eseguire indirettamente un attivatore. Ad esempio, un utente può richiamare indirettamente un trigger quando esegue il push di nuovo codice sorgente a un repository connesso. Qualsiasi utente con il ruolo Editor Cloud Build può aggiornare un trigger a condizione che l'account di servizio precedente e quello nuovo specificati sul trigger siano l'account Cloud Build predefinito.

  • Account di servizio specificato dall'utente: qualsiasi utente con il ruolo Editor di Cloud Build che dispone dell'autorizzazione iam.serviceAccounts.actAs 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 esegue il push di una nuova origine in un repository connesso. Qualsiasi utente con il ruolo Editor Cloud Build può aggiornare un trigger a condizione che disponga delle autorizzazioni iam.serviceAccounts.actAs sia nell'account di servizio configurato in precedenza sia nel nuovo account specificato nel trigger. Per concedere questa autorizzazione a un utente, puoi concedergli 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 concederlo all'utente. Per scoprire di più sulle autorizzazioni degli account di servizio, consulta Ruoli per l'autenticazione degli account di servizio.

Inoltre, l'account di servizio predefinito di Cloud Build e gli account di servizio specificati dall'utente possono fornire autorizzazioni elevate in fase di build agli utenti che utilizzano trigger per richiamare una build. Tieni presente le seguenti implicazioni per la sicurezza quando utilizzi i trigger di build associati all'account di servizio Cloud Build predefinito:

  • Un utente che non ha accesso al tuo progetto Google Cloud, ma ha accesso in scrittura al repository associato ai trigger di build nel progetto, disporrà delle autorizzazioni per modificare il codice in fase di creazione.
  • Se utilizzi trigger per le richieste di pull GitHub, qualsiasi utente con accesso in lettura al repository può inviare una richiesta di pull, il che potrebbe attivare una build che include modifiche al codice nella richiesta di pull. Puoi disabilitare questo comportamento scegliendo l'opzione Controllo dei commenti durante la creazione di un trigger di richiesta di pull GitHub. Se selezioni questa opzione, la build verrà avviata solo se un proprietario del repository o un collaboratore commenta /gcbrun. Per informazioni sull'uso del controllo dei commenti con i trigger di GitHub, consulta la pagina sulla creazione di trigger GitHub.

Limitazioni

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

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

Per le istruzioni, vedi Autorizzare l'accesso da servizio a servizio.

Passaggi successivi