Cloud Build è un servizio che esegue le tue build su Google Cloud.
Cloud Build può importare codice sorgente da una varietà di repository o Cloud Storage, eseguire una build secondo le tue specifiche e produrre artefatti come container Docker o archivi Java. Puoi anche utilizzare Cloud Build per proteggere la tua catena di fornitura del software. Le funzionalità di Cloud Build soddisfano i requisiti del livello 3 di Supply chain Levels for Software Artifacts (SLSA). Per indicazioni su come proteggere i processi di build, consulta Proteggere le build.Configurazione di compilazione e passaggi di build
Puoi scrivere una configurazione di build per fornire istruzioni a Cloud Build su quali attività eseguire. Puoi configurare le build per recuperare dipendenze, eseguire test delle unità, analisi statiche e test di integrazione e creare artefatti con strumenti di build come Docker, Gradle, Maven, Bazel e gulp.
Cloud Build esegue la build come una serie di passaggi di build, dove ogni passaggio viene eseguito in un container Docker. L'esecuzione di passaggi di build è analoga all'esecuzione di comandi in uno script.
Puoi usare i passaggi di build forniti da Cloud Build e dalla sua community o scrivere passaggi di build personalizzati:
- Passaggi di build forniti da Cloud Build: Cloud Build ha pubblicato un insieme di passaggi di build open source supportati per linguaggi e attività comuni.
- Passaggi di build forniti dalla community: la community di utenti di Cloud Build ha fornito passaggi di build open source.
- Passaggi di build personalizzati: puoi creare i tuoi passaggi di build da utilizzare nelle build.
Ogni passaggio di build viene eseguito con il relativo container collegato a una rete Docker locale denominata cloudbuild. In questo modo, i passaggi di build possono comunicare tra loro e condividere i dati. Per ulteriori informazioni sulla rete cloudbuild, consulta
Rete Cloud Build.
Puoi utilizzare le immagini standard di Docker Hub in Cloud Build, ad esempio Ubuntu e Gradle.
Avvio delle build
Puoi avviare manualmente le build in Cloud Build utilizzando Google Cloud CLI o l'API di Cloud Build, oppure utilizzare i trigger di build di Cloud Build per creare un flusso di lavoro di integrazione continua/distribuzione continua (CI/CD) automatizzato che avvia nuove build in risposta alle modifiche del codice. Puoi integrare i trigger di build con molti repository di codice, tra cui Cloud Source Repositories, GitHub e Bitbucket.Visualizzazione dei risultati della build
Puoi visualizzare i risultati della build utilizzando gcloud CLI, l' API Cloud Build o la pagina Cronologia build nella sezione Cloud Build della Google Cloud console, che mostra i dettagli e i log di ogni build eseguita da Cloud Build. Per le istruzioni, consulta Visualizzare i risultati della build.
Come funzionano le build
I seguenti passaggi descrivono, in generale, il ciclo di vita di una build Cloud Build:
- Prepara il codice dell'applicazione e gli asset necessari.
- Crea un file di configurazione di build in formato YAML o JSON, che contiene le istruzioni per Cloud Build.
- Invia la build a Cloud Build.
- Cloud Build esegue la build in base alla configurazione di build che hai fornito.
- Se applicabile, tutti gli artefatti creati vengono inviati ad Artifact Registry.
Docker
Cloud Build utilizza Docker
per eseguire le build. Per ogni passaggio di build, Cloud Build esegue un container Docker come istanza di docker run. Al momento, Cloud Build esegue la versione 20.10.24 del motore Docker.
Interfacce di Cloud Build
Puoi utilizzare Cloud Build con la Google Cloud console, gcloud
strumento a riga di comando o l'API REST di Cloud Build.
Puoi utilizzare gcloud CLI per creare e gestire le build. Puoi eseguire comandi per svolgere attività come l'invio di una build, l'elenco delle build, e l'annullamento di una build.
Puoi richiedere le build utilizzando l'API REST di Cloud Build.
Come per le altre API di Google Cloud, devi autorizzare l'accesso utilizzando OAuth2. Dopo aver autorizzato l'accesso, puoi utilizzare l'API per avviare nuove build, visualizzare lo stato e i dettagli delle build, elencare le build per progetto e annullare le build attualmente in corso.
Per ulteriori informazioni, consulta la documentazione dell'API.
Pool predefiniti e pool privati
Per impostazione predefinita, quando una build su Cloud Build viene eseguita in un ambiente sicuro ospitato con accesso alla rete internet pubblica. Ogni build viene eseguita sul proprio worker ed è isolata da altri carichi di lavoro. Puoi personalizzare la build in diversi modi, ad esempio aumentando le dimensioni del tipo di macchina o allocando più spazio su disco. Il pool predefinito ha limiti alla personalizzazione dell'ambiente, in particolare per quanto riguarda l'accesso alla rete privata.
I pool privati sono pool di worker privati e dedicati che offrono una maggiore personalizzazione dell'ambiente di build, inclusa la possibilità di accedere alle risorse in una rete privata. I pool privati, come i pool predefiniti, sono ospitati e completamente gestiti da Cloud Build e fanno lo scale up e lo scale down fino a zero, senza infrastrutture per configurazione, upgrade o scalabilità. Poiché i pool privati sono risorse specifiche del cliente, puoi configurarli in più modi.Per scoprire di più sui pool privati e sulla differenza di funzionalità tra il pool predefinito e il pool privato, consulta Panoramica dei pool privati.
Sicurezza delle build
Cloud Build fornisce diverse funzionalità per proteggere le build, tra cui:
-
Build automatizzate
Una build automatizzata o una build con script definisce tutti i passaggi di build nello script di build o nella configurazione di compilazione, inclusi i passaggi per recuperare il codice sorgente e i passaggi per creare il codice. L'unico comando manuale, se presente, è il comando per eseguire la build. Cloud Build utilizza un file di configurazione di build per fornire i passaggi di build a Cloud Build.
Le build automatizzate garantiscono la coerenza dei passaggi di build. Tuttavia, è anche importante eseguire le build in un ambiente coerente e attendibile.
Sebbene le build locali possano essere utili per il debug, il rilascio di software da build locali può introdurre molti problemi di sicurezza, incoerenze e inefficienze nel processo di compilazione.
- Consentire le build locali offre a un attaccante con intenti dannosi un modo per modificare il processo di compilazione.
- Le incoerenze negli ambienti locali degli sviluppatori e nelle pratiche degli sviluppatori rendono difficile riprodurre le build e diagnosticare i problemi di build.
Nei requisiti per il framework SLSA, le build automatizzate sono un requisito per il livello 1 di SLSA e l'utilizzo di un servizio di build anziché di ambienti di sviluppo per le build è un requisito per il livello 2 di SLSA.
-
Provenienza della build
La provenienza della build è una raccolta di dati verificabili su una build.
I metadati di provenienza includono dettagli come i digest delle immagini create , le località della sorgente di ingresso, la toolchain di build e la durata della build.
La generazione della provenienza della build ti aiuta a:
- Verificare che un artefatto creato sia stato creato da una località di origine attendibile e da un sistema di compilazione attendibile.
- Identificare il codice inserito da una località di origine o da un sistema di build non attendibile.
Puoi utilizzare meccanismi di avviso e policy per utilizzare in modo proattivo i dati di provenienza della build Ad esempio, puoi creare policy che consentano solo i deployment di codice creato da origini verificate.
Cloud Build può generare la provenienza della build per le immagini container che forniscono la garanzia del livello 3 di SLSA. Per ulteriori informazioni, consulta Visualizzare la provenienza della build.
-
Ambiente di build temporaneo
Gli ambienti temporanei sono ambienti temporanei destinati a durare per una singola chiamata di build. Al termine della build, l'ambiente viene cancellato o eliminato. Le build temporanee garantiscono che il servizio di build e i passaggi di build vengano eseguiti in un ambiente temporaneo, ad esempio un container o una macchina virtuale (VM). Anziché riutilizzare un ambiente di build esistente, il servizio di build esegue il provisioning di un nuovo ambiente per ogni build e lo elimina al termine del processo di compilazione.
Gli ambienti temporanei garantiscono build pulite, poiché non sono presenti file residui o impostazioni di ambiente di build precedenti che possono interferire con il processo di build. Un ambiente non temporaneo offre agli utenti malintenzionati l'opportunità di inserire file e contenuti dannosi. Un ambiente temporaneo riduce anche il sovraccarico di manutenzione e riduce le incoerenze nell'ambiente di build
Cloud Build configura un nuovo ambiente VM per ogni build e lo elimina al termine della build.
-
Criteri di deployment
Puoi integrare Cloud Build con Autorizzazione binaria per verificare le attestazioni di build e bloccare i deployment di immagini non generate da Cloud Build. Questo processo può ridurre il rischio di deployment di software non autorizzato.
-
Chiavi di crittografia gestite dal cliente
Per impostazione predefinita, Cloud Build fornisce la conformità alle chiavi di crittografia gestite dal cliente (CMEK). Gli utenti non devono configurare nulla di specifico. Cloud Build fornisce la conformità CMEK criptando il disco permanente (DP) in fase di build con una chiave temporanea generata per ogni build. La chiave viene generata in modo univoco per ogni build.
Al termine della build, la chiave viene cancellata dalla memoria ed eliminata. Non viene archiviata da nessuna parte, non è accessibile agli ingegneri o al personale di assistenza di Google e non può essere ripristinata. I dati protetti con una chiave di questo tipo non sono accessibili in modo permanente. Per ulteriori informazioni, consulta Conformità di CMEK in Cloud Build.
-
Riquadro Approfondimenti sulla sicurezza
Cloud Build include un riquadro Approfondimenti sulla sicurezza nella console che mostra una panoramica di alto livello di più metriche di sicurezza. Google Cloud Puoi utilizzare questo riquadro per identificare e mitigare i rischi nel processo di compilazione.
Questo riquadro mostra le seguenti informazioni:
- Livello di Supply chain Levels for Software Artifacts (SLSA): identifica il livello di maturità del processo di compilazione del software in conformità con la specifica SLSA.
- Vulnerabilità: una panoramica di tutte le vulnerabilità rilevate negli artefatti e il nome dell'immagine sottoposta a scansione da Artifact Analysis. Puoi fare clic sul nome dell'immagine per visualizzare i dettagli della vulnerabilità
- Dettagli build: dettagli della build, ad esempio il builder e il link per visualizzare i log.
- Provenienza della build: provenienza della build.
Per scoprire come utilizzare Cloud Build con altri Google Cloud prodotti e funzionalità per proteggere la catena di fornitura del software, consulta Sicurezza della catena di fornitura del software.