Le pipeline di deployment consentono di automatizzare il processo di acquisizione del codice o di artefatti predefiniti e di eseguirne il deployment in un ambiente Google Cloud e possono essere un'alternativa all'utilizzo di strumenti interattivi come la console Google Cloud o Google Cloud CLI.
Le pipeline di deployment sono diverse da strumenti interattivi come la console Google Cloud o gcloud CLI per il modo in cui interagiscono con Identity and Access Management e devi tenere in considerazione queste differenze quando proteggi le tue risorse Google Cloud.
Prima che Google Cloud ti consenta di accedere a una risorsa, esegue un controllo dell'accesso. Per eseguire questo controllo, in genere IAM considera:
- La tua identità
- La risorsa a cui stai tentando di accedere e i relativi criteri di autorizzazione e negazione IAM
- Il contesto della tua richiesta (che può includere ora e luogo)
In una pipeline di deployment, raramente chiami direttamente le API Google Cloud. ma utilizzerai gli strumenti per accedere alle risorse Google Cloud. Strumenti come la console Google Cloud o gcloud CLI richiedono prima di autorizzare lo strumento ad accedere alle risorse per tuo conto. Fornendo questa autorizzazione, autorizzi lo strumento a utilizzare la tua identità quando effettui chiamate API.
Come la console Google Cloud o gcloud CLI, una pipeline di deployment agisce per tuo conto: prende le tue modifiche, espresse come codice sorgente, e ne esegue il deployment su Google Cloud. Ma a differenza della console Google Cloud o di gcloud CLI, una pipeline di deployment solitamente non utilizza la tua identità per eseguire il deployment:
Come utente, in genere non interagisci direttamente con una pipeline di deployment. Puoi invece interagire con un sistema di controllo del codice sorgente (SCM) eseguendo il push delle modifiche del codice a un repository di codice sorgente o approvando le revisioni del codice.
La pipeline di deployment legge le modifiche al codice inviate dal sistema SCM e ne esegue il deployment in Google Cloud.
Per eseguire il deployment, la pipeline di deployment in genere non può utilizzare la tua identità perché:
- Il codice sorgente e i relativi metadati potrebbero non indicare che sei l'autore oppure le informazioni sull'autore non sono a prova di manomissione (come nel caso dei commit Git non firmati)
- L'identità utilizzata per inviare il codice sorgente potrebbe essere diversa da quella di Google e le due identità non possono essere mappate
Pertanto, la maggior parte delle pipeline di deployment esegue i deployment con la propria identità utilizzando un account di servizio.
Quando la pipeline di deployment accede a Google Cloud, IAM consente o nega l'accesso esclusivamente in base all'identità dell'account di servizio utilizzato dalla pipeline, non all'identità del tuo account utente.
Consentire a una pipeline di deployment di utilizzare un account di servizio per accedere a Google Cloud offre alcuni vantaggi:
- Il ciclo di vita di un account di servizio è disconnesso dal ciclo di vita degli account utente. Configurando una pipeline per l'utilizzo di un account di servizio, ti assicuri che sia possibile eseguire il deployment del codice anche se l'autore del codice non fa più parte della tua organizzazione.
- Quando gestisci le risorse utilizzando una pipeline di deployment, non devi concedere agli utenti alcun accesso alle risorse oppure puoi limitare le autorizzazioni all'accesso in sola lettura. Questo approccio semplifica la gestione dei criteri IAM e consente di forzare gli utenti a utilizzare la pipeline di deployment per eseguire tutte le modifiche.
Tuttavia, l'utilizzo di un account di servizio introduce anche nuove minacce. Queste includono:
- Spoofing: un malintenzionato potrebbe tentare di falsificare l'identità della pipeline di deployment o rubarne le credenziali per accedere alle risorse.
- Escalation dei privilegi: la pipeline potrebbe essere indotta con l'inganno a eseguire azioni che non dovrebbe eseguire, diventando di fatto un viceconfuso.
- Non ripudio: dopo che una pipeline ha eseguito un'operazione, potrebbe essere difficile ricostruire il motivo per cui l'operazione è stata attivata e lo sviluppatore o la modifica del codice da cui è stata attivata.
- Manomissione: una pipeline potrebbe essere utilizzata in modo illecito per minare l'integrità o i controlli di sicurezza dei tuoi ambienti cloud.
- Divulgazione di informazioni: i malintenzionati potrebbero tentare di utilizzare la pipeline di deployment per esfiltrare i dati riservati.
Proteggiti dalle minacce di spoofing
Per concedere a Google Cloud l'accesso alla pipeline di deployment, in genere esegui queste operazioni:
- Crea un account di servizio
- Concedi all'account di servizio l'accesso alle risorse richieste
- Configura la pipeline di deployment per utilizzare l'account di servizio
Dal punto di vista di IAM, l'account di servizio rappresenta la pipeline di deployment, ma la pipeline di deployment e l'account di servizio sono due entità separate. Se non viene protetta correttamente, un utente malintenzionato potrebbe essere in grado di utilizzare lo stesso account di servizio, il che consente di eseguire lo spoofing dell'identità della pipeline di deployment.
La seguente sezione descrive le best practice che possono aiutarti a ridurre il rischio di queste minacce.
Best practice:
Evita di collegare account di servizio alle istanze VM utilizzate dai sistemi CI/CD.Utilizza account di servizio dedicati per ogni pipeline di deployment.
Utilizza la federazione delle identità per i carichi di lavoro quando possibile.
Utilizza i Controlli di servizio VPC per ridurre l'impatto delle credenziali divulgate.
Evita di collegare account di servizio alle istanze VM utilizzate dai sistemi CI/CD
Per le applicazioni di cui è stato eseguito il deployment in Compute Engine che richiedono l'accesso alle risorse Google Cloud, in genere è preferibile collegare un account di servizio all'istanza VM sottostante. Per i sistemi CI/CD che utilizzano le VM di Compute Engine per eseguire pipeline di deployment diverse, questa pratica può risultare problematica se la stessa istanza VM può essere utilizzata per eseguire pipeline di deployment diverse, ognuna delle quali richiede l'accesso a risorse diverse.
Anziché utilizzare account di servizio collegati per consentire alle pipeline di deployment di accedere alle risorse, consenti a ogni pipeline di deployment di utilizzare un account di servizio separato. Evita di collegare un account di servizio a istanze VM utilizzate da sistemi CI/CD oppure collega un account di servizio limitato all'accesso solo a servizi essenziali come Cloud Logging.
Usa account di servizio dedicati per pipeline di deployment
Se consenti a più pipeline di deployment di utilizzare lo stesso account di servizio, IAM non è in grado di distinguere tra le pipeline: le pipeline hanno accesso alle stesse risorse e gli audit log potrebbero non contenere informazioni sufficienti per determinare quale pipeline di deployment ha attivato l'accesso o la modifica di una risorsa.
Per evitare ambiguità, mantieni una relazione 1:1 tra le pipeline di deployment e gli account di servizio. Crea un account di servizio dedicato per ogni pipeline di deployment e assicurati di:
- Incorpora il nome o l'ID della pipeline di deployment nell'indirizzo email dell'account di servizio. Seguendo uno schema di denominazione coerente puoi determinare la pipeline di deployment dal nome dell'account di servizio e viceversa.
- Concedi all'account di servizio l'accesso solo alle risorse necessarie alla pipeline di deployment specifica.
Utilizza la federazione delle identità per i carichi di lavoro quando possibile
Alcuni sistemi CI/CD come GitHub Actions o GitLab consentono alle pipeline di deployment di ottenere token compatibili con OpenID Connect che rivendicano l'identità della pipeline di deployment. Puoi consentire alle pipeline di deployment di utilizzare questi token per impersonare un account di servizio utilizzando la federazione delle identità per i carichi di lavoro.
L'utilizzo della federazione delle identità per i carichi di lavoro consente di evitare i rischi associati all'utilizzo delle chiavi degli account di servizio.
Utilizza i Controlli di servizio VPC per ridurre l'impatto delle credenziali divulgate
Se un utente malintenzionato riesce a rubare un token di accesso o una chiave dell'account di servizio da una delle pipeline di deployment, potrebbe tentare di utilizzare questa credenziale e accedere alle tue risorse da una macchina diversa che controlla.
Per impostazione predefinita, IAM non prende in considerazione la geolocalizzazione, l'indirizzo IP di origine o il progetto Google Cloud di origine per prendere decisioni di accesso. Pertanto, una credenziale rubata potrebbe essere utilizzabile ovunque.
Puoi imporre restrizioni sulle origini da cui è possibile accedere alle risorse Google Cloud posizionando i progetti in un perimetro di servizio VPC e utilizzando le regole in entrata:
- Se la pipeline di deployment viene eseguita su Google Cloud, puoi configurare una regola in entrata per consentire l'accesso solo dal progetto che contiene il tuo sistema CI/CD.
- Se la pipeline di deployment viene eseguita al di fuori di Google Cloud, puoi creare un livello di accesso che consenta solo l'accesso da determinate località geografiche o intervalli IP. Quindi, crea una regola in entrata che consenta l'accesso ai client che soddisfano questo livello di accesso.
Proteggiti dalle minacce di manomissioni
Per alcuni dati archiviati su Google Cloud, potrebbe essere particolarmente importante impedire la modifica o l'eliminazione non autorizzata. Se la modifica o l'eliminazione non autorizzata è di particolare interesse, puoi classificare i dati come dati ad alta integrità.
Per mantenere l'integrità dei dati, devi assicurarti che le risorse Google Cloud che utilizzi per archiviare e gestire i dati siano configurate in modo sicuro e devono mantenere la loro integrità.
Le pipeline di deployment possono aiutarti a mantenere l'integrità dei tuoi dati e delle tue risorse, ma possono anche rappresentare un rischio: se la pipeline di uno dei suoi componenti non soddisfa i requisiti di integrità delle risorse che gestisce, la pipeline di deployment si trasforma in un punto debole che potrebbe consentire ai malintenzionati di manomettere i dati o le risorse.
La seguente sezione descrive le best practice che possono aiutarti a ridurre il rischio di minacce di manomissione.
Limitare l'accesso ai controlli di sicurezza
Per garantire la sicurezza e l'integrità dei tuoi dati e delle tue risorse su Google Cloud, utilizza controlli di sicurezza come:
- Consenti e nega i criteri
- Vincoli dei criteri dell'organizzazione
- Perimetri, livelli di accesso e criteri in entrata dei Controlli di servizio VPC
Questi controlli di sicurezza sono risorse a sé stanti. La manomissione dei controlli di sicurezza compromette l'integrità delle risorse a cui si applicano i controlli di sicurezza. Di conseguenza, devi considerare che l'integrità dei controlli di sicurezza sia importante almeno quanto l'integrità delle risorse a cui si applicano.
Se consenti a una pipeline di deployment di gestire i controlli di sicurezza, spetta alla pipeline di deployment mantenere l'integrità dei controlli di sicurezza. Di conseguenza, è necessario considerare che l'integrità della pipeline di deployment stessa sia importante almeno quanto l'integrità dei controlli di sicurezza che gestisce e le risorse a cui si applicano questi controlli.
Puoi limitare l'impatto di una pipeline di deployment sull'integrità delle risorse:
- Non concedere l'accesso alle pipeline di deployment per consentire criteri, criteri di negazione e altri controlli di sicurezza e limitare il loro accesso ad altre risorse
- Concedere l'accesso solo a controlli di sicurezza selezionati, ad esempio i criteri di autorizzazione e di negazione di una risorsa o un progetto specifico, senza concedere l'accesso a controlli più ampi che interessano più risorse o progetti
Se la tua pipeline di deployment, i suoi componenti e l'infrastruttura sottostante non soddisfano le esigenze di integrità di determinati controlli di sicurezza, è meglio evitare di lasciare che siano le pipeline di deployment a gestire questi controlli di sicurezza.
Proteggiti dalle minacce di non ripudio
A un certo punto, potresti notare attività sospette che interessano una delle tue risorse su Google Cloud. In questo caso, devi essere in grado di saperne di più sull'attività e, idealmente, essere in grado di ricostruire la catena di eventi che l'hanno portato.
Cloud Audit Logs consente di sapere quando è stato effettuato l'accesso o la modifica alle risorse e quali utenti sono stati coinvolti. Sebbene Cloud Audit Logs fornisca un punto di partenza per l'analisi delle attività sospette, le informazioni fornite da questi log potrebbero non essere sufficienti: se utilizzi pipeline di deployment, devi anche essere in grado di correlare gli audit log di Cloud ai log prodotti dalla pipeline di deployment.
Questa sezione contiene best practice utili per gestire un audit trail su Google Cloud e le pipeline di deployment.
Best practice:
Assicurati di poter correlare i log delle pipeline di deployment con Cloud Audit Logs.Allinea i periodi di conservazione dei log delle pipeline di deployment e di Cloud Audit Logs.
Assicurati di poter correlare i log delle pipeline di deployment con Cloud Audit Logs
Cloud Audit Logs contiene timestamp e informazioni sull'utente che ha avviato un'attività. Se utilizzi un account di servizio dedicato per ogni pipeline di deployment, queste informazioni ti consentono di identificare la pipeline di deployment che ha avviato l'attività e potrebbero anche aiutarti a restringere le modifiche al codice e le esecuzioni della pipeline che potrebbero essere state responsabili. Tuttavia, identificare l'esecuzione esatta della pipeline e la modifica del codice che ha portato all'attività può essere difficile senza ulteriori informazioni che ti permettano di correlare Cloud Audit Logs con i log della tua pipeline di deployment.
Puoi arricchire Cloud Audit Logs in modo che contenga maggiori informazioni in diversi modi, tra cui:
- Quando utilizzi Terraform, specifica un motivo della richiesta che indichi l'esecuzione della pipeline CI/CD.
- Aggiungi un'intestazione HTTP
X-Goog-Request-Reasonalle richieste API e trasmetti l'ID dell'esecuzione della pipeline di deployment. - Utilizza un
User-Agentpersonalizzato che incorpora l'ID dell'esecuzione della pipeline di deployment.
Puoi anche arricchire i log emessi dalla tua pipeline di deployment:
- Richieste API Log eseguite da ogni esecuzione della pipeline CI/CD.
- Ogni volta che l'API restituisce un ID operazione, registralo nei log del sistema CI/CD.
Allinea i periodi di conservazione dei log delle pipeline di deployment e di Cloud Audit Logs
Per analizzare le attività sospette relative a una pipeline di deployment, in genere sono necessari più tipi di log, inclusi gli audit log dell'attività di amministrazione, gli audit log degli accessi ai dati e i log della pipeline di deployment.
Cloud Logging conserva i log solo per un determinato periodo di tempo. Per impostazione predefinita, questo periodo di conservazione è più breve per gli audit log degli accessi ai dati rispetto agli audit log dell'attività di amministrazione. Anche il sistema che esegue la pipeline di deployment potrebbe eliminare i log dopo un determinato periodo di tempo. A seconda della natura della pipeline di deployment e dell'importanza delle risorse gestite dalla pipeline di deployment, questi periodi di conservazione predefiniti potrebbero essere insufficienti o disallineati.
Per assicurarti che i log siano disponibili quando ne hai bisogno, assicurati che i periodi di conservazione dei log utilizzati dai diversi sistemi siano allineati e sufficientemente lunghi.
Se necessario, personalizza il periodo di conservazione per gli audit log di accesso ai dati oppure configura un sink personalizzato per indirizzare i log a una posizione di archiviazione personalizzata.
Best practice:
Evita di concedere l'accesso diretto ai dati riservati.Utilizza i Controlli di servizio VPC per prevenire l'esfiltrazione di dati.
Proteggiti dalle minacce alla divulgazione di informazioni
Quando l'account di servizio di una pipeline di deployment ha accesso a dati riservati, un utente malintenzionato potrebbe tentare di utilizzare la pipeline di deployment per esfiltrarli. L'accesso ai dati di una pipeline di deployment può essere diretto o indiretto:
Diretto: l'account di servizio della pipeline di deployment potrebbe disporre dell'autorizzazione per leggere dati riservati da Cloud Storage, BigQuery o altre posizioni. Questo accesso potrebbe essere stato concesso intenzionalmente, ma potrebbe anche essere un risultato accidentale della concessione di un accesso eccessivo.
Se un utente malintenzionato riesce ad accedere a una pipeline di deployment con accesso diretto ai dati riservati, potrebbe provare a utilizzare il token di accesso dell'account di servizio per accedere ai dati ed esfiltrarli.
Indiretto: per eseguire il deployment della configurazione o di nuove versioni software, l'account di servizio di una pipeline di deployment potrebbe disporre dell'autorizzazione per creare o ripetere il deployment di istanze VM, applicazioni Cloud Run o altre risorse di calcolo. Alcune di queste risorse di calcolo potrebbero avere un account di servizio collegato che concede l'accesso a dati riservati.
In questa situazione, un malintenzionato potrebbe tentare di compromettere la pipeline di deployment, in modo da eseguire il deployment di codice dannoso in una delle risorse di computing, e lasciare che il codice esfiltra i dati riservati.
Questa sezione contiene delle best practice che possono aiutarti a limitare il rischio di divulgazione di dati riservati.
Evita di concedere l'accesso diretto ai dati riservati
Per eseguire il deployment dell'infrastruttura, della configurazione o di nuove versioni software, una pipeline di deployment spesso non richiede l'accesso ai dati esistenti. Invece, spesso è sufficiente limitare l'accesso alle risorse che non contengono dati o almeno non contengono dati riservati.
Ecco alcuni modi per ridurre al minimo l'accesso ai dati esistenti e potenzialmente riservati:
- Anziché concedere all'account di servizio di una pipeline di deployment l'accesso a un intero progetto, concedi l'accesso solo a risorse specifiche.
- Concedi l'accesso in creazione senza consentire l'accesso in lettura. Ad esempio, assegnando il ruolo Creatore oggetti Storage (
roles/storage.objectCreator), puoi consentire a un account di servizio di caricare nuovi oggetti in un bucket Cloud Storage senza concedere l'autorizzazione per leggere i dati esistenti. - Limita Infrastructure as Code (IaC) a risorse meno riservate. Ad esempio, utilizza IaC per la gestione di reti o istanze VM, ma non per la gestione di set di dati BigQuery riservati.
Utilizzare i Controlli di servizio VPC per prevenire l'esfiltrazione di dati
Puoi ridurre il rischio di esfiltrazione indiretta dei dati eseguendo il deployment delle tue risorse Google Cloud in un perimetro dei Controlli di servizio VPC.
Se la pipeline di deployment viene eseguita al di fuori di Google Cloud o fa parte di un perimetro diverso, puoi concedere all'account di servizio della pipeline l'accesso al perimetro configurando una regola in entrata. Se possibile, configura la regola in entrata in modo che consenta l'accesso solo dagli indirizzi IP utilizzati dalla pipeline di deployment e consenta solo l'accesso ai servizi effettivamente necessari per la pipeline di deployment.
Proteggiti dalle minacce di escalation dei privilegi
Quando una pipeline di deployment utilizza un account di servizio per accedere alle risorse Google Cloud, ciò avviene indipendentemente dallo sviluppatore o dall'utente che ha creato una modifica al codice o alla configurazione. La disconnessione tra l'account di servizio della pipeline e l'identità dello sviluppatore rende le pipeline di deployment soggette ad attacchi di tipo viceconfuso, in cui un utente malintenzionato induce con l'inganno la pipeline a eseguire un'azione che l'utente malintenzionato non è autorizzato a compiere e che la pipeline potrebbe non essere nemmeno prevista.
Questa sezione contiene le best practice che possono aiutarti a ridurre il rischio di utilizzo illecito della pipeline di deployment per l'escalation dei privilegi.
Best practice:
Limita l'accesso alla pipeline di deployment e a tutti gli input.Evita di consentire a una pipeline di deployment di modificare i criteri.
Non rivelare le credenziali dell'account di servizio nei log.
Limita l'accesso alla pipeline di deployment e a tutti gli input
La maggior parte delle pipeline di deployment utilizza un repository di codice sorgente come origine principale di input e potrebbe attivarsi automaticamente non appena rileva una modifica del codice in determinati rami (ad esempio, il ramo main). In genere le pipeline di deployment non sono in grado di verificare se il codice e la configurazione che trovano nel repository del codice sorgente sono autentici e affidabili. La sicurezza di questa architettura dipende quindi da:
- Controllando chi può inviare codice e configurazione al repository e ai rami utilizzati dalla pipeline di deployment.
- Applicare criteri che devono essere soddisfatti prima di eseguire il commit delle modifiche, ad esempio revisioni del codice riuscite, analisi statiche o test automatici.
Affinché questi controlli siano efficaci, devi anche assicurarti che i malintenzionati non possano evitarli:
- Modificare la configurazione del repository del codice sorgente o della pipeline di deployment.
- Manomissione dell'infrastruttura (ad esempio VM e archiviazione) alla base della pipeline di deployment.
- Modifica o sostituzione di input al di fuori del repository del codice sorgente, ad esempio pacchetti, immagini container o librerie.
Se gestite da una pipeline di deployment, le risorse su Google Cloud possono essere sicure quanto la pipeline di deployment, la configurazione, l'infrastruttura e gli input. Di conseguenza, devi proteggere questi componenti e vuoi che le tue risorse Google Cloud siano protette.
Evita di consentire a una pipeline di deployment di modificare i criteri
Per la maggior parte dei tipi di risorse, IAM definisce un'autorizzazione RESOURCE_TYPE.setIamPolicy. Questa autorizzazione consente a un utente di modificare il criterio di autorizzazione IAM di una risorsa per concedere l'accesso ad altri utenti o per modificare ed estendere il proprio accesso. A meno che non sia vincolata da un criterio di negazione, la concessione a un account utente o di servizio di un'autorizzazione *.setIamPolicy ha l'effetto di concedere a un account utente l'accesso completo alla risorsa.
Se possibile, evita di consentire a una pipeline di deployment di modificare l'accesso alle risorse.
Quando concedi all'account di servizio della pipeline l'accesso alle risorse Google Cloud, utilizza ruoli che non includono autorizzazioni *.setIamPolicy ed evita di utilizzare i ruoli di base Editor e Proprietario.
Per alcune pipeline di deployment, la concessione dell'autorizzazione per modificare i criteri di autorizzazione o i criteri di negazione potrebbe essere inevitabile: ad esempio, lo scopo di una pipeline di deployment potrebbe essere creare nuove risorse o gestire l'accesso alle risorse esistenti. In questi scenari, puoi comunque limitare la misura in cui il deployment può modificare l'accesso:
- Concede l'autorizzazione
*.setIamPolicysolo per risorse specifiche, non per l'intero progetto. - L'utilizzo dei criteri di negazione IAM per vincolare l'insieme di autorizzazioni che è possibile concedere o per limitare le entità a cui possono essere concesse.
- Utilizzo delle condizioni IAM per limitare i ruoli che la pipeline è autorizzata a concedere e consentire solo i ruoli che
non includono le autorizzazioni
*.setIamPolicy.
Non rivelare le credenziali dell'account di servizio nei log
I log generati da una pipeline di deployment sono spesso accessibili a un gruppo più ampio di utenti, inclusi quelli che non dispongono dell'autorizzazione per modificare la configurazione della pipeline. È possibile che questi log rivelino accidentalmente le credenziali tramite l'eco:
- Contenuti delle variabili di ambiente
- Argomenti della riga di comando
- Output diagnostica
Se i log rivelano accidentalmente credenziali, ad esempio i token di accesso, queste credenziali potrebbero essere utilizzate in modo illecito dai malintenzionati per aumentare i loro privilegi. Ecco alcuni modi per impedire ai log di rivelare le credenziali:
- Evita di trasmettere token di accesso o altre credenziali come argomenti della riga di comando
- Evita di archiviare le credenziali nelle variabili di ambiente
- Configura il tuo sistema CI/CD per rilevare e mascherare automaticamente i token e altre credenziali, se possibile
Passaggi successivi
- Scopri di più sulla federazione delle identità per i carichi di lavoro e sulle best practice per l'utilizzo della federazione delle identità per i carichi di lavoro .
- Esamina il nostro progetto della piattaforma aziendale e le indicazioni su autenticazione e autorizzazione.
- Scopri di più sulle best practice per lavorare con gli account di servizio.