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:
|
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:
|
source.repos.list |
Può elencare i repository in Cloud Source Repositories | |
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 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 autorizzazioniiam.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'autorizzazioneiam.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
- 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 di Cloud Build.
- Scopri di più sulle autorizzazioni necessarie per visualizzare i log di build.