GCP - Cloud Build Enum
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Google Cloud Build è una piattaforma CI/CD gestita che automazione i processi di build e rilascio del software, integrandosi con repository di codice sorgente e supportando un'ampia gamma di linguaggi di programmazione. Permette agli sviluppatori di costruire, testare e distribuire codice automaticamente fornendo flessibilità per personalizzare i passaggi di build e i flussi di lavoro.
Ogni Trigger di Cloud Build è collegato a un Cloud Repository o direttamente connesso a un repository esterno (Github, Bitbucket e Gitlab).
Non ho visto alcun modo per rubare il token di Github/Bitbucket da qui o dai Cloud Repositories perché quando il repo viene scaricato viene accesso tramite un URL https://source.cloud.google.com/ e Github non è accessibile dal client.
Il Cloud Build può essere attivato se:
Push su un branch: Specificare il branch
Push di un nuovo tag: Specificare il tag
Pull request: Specificare il branch che riceve il PR
Invocazione manuale
Messaggio Pub/Sub: Specificare l'argomento
Evento Webhook: Esporrà un URL HTTPS e la richiesta deve essere autenticata con un segreto
Ci sono 3 opzioni:
Un yaml/json che specifica i comandi da eseguire. Di solito: /cloudbuild.yaml
Solo uno che può essere specificato “inline” nella console web e nella cli
Opzione più comune
Rilevante per accesso non autenticato
Un Dockerfile da costruire
Un Buildpack da costruire
Il Service Account ha l'ambito cloud-platform
, quindi può utilizzare tutti i privilegi. Se non viene specificato alcun SA (come quando si fa submit) verrà utilizzato il SA predefinito <proj-number>@cloudbuild.gserviceaccount.com
.
Per impostazione predefinita, non vengono concessi permessi, ma è abbastanza facile concederne alcuni:
È possibile configurare un Cloud Build per richiedere approvazioni per le esecuzioni di build (disabilitato per impostazione predefinita).
Quando il trigger è PR perché chiunque può eseguire PR su repository pubblici sarebbe molto pericoloso consentire l'esecuzione del trigger con qualsiasi PR. Pertanto, per impostazione predefinita, l'esecuzione sarà automatica solo per i proprietari e i collaboratori, e per eseguire il trigger con PR di altri utenti un proprietario o collaboratore deve commentare /gcbrun
.
Le connessioni possono essere create su:
GitHub: Mostrerà un prompt OAuth che chiede permessi per ottenere un token di Github che sarà memorizzato all'interno del Secret Manager.
GitHub Enterprise: Chiederà di installare un GithubApp. Un token di autenticazione dal tuo host GitHub Enterprise sarà creato e memorizzato in questo progetto come un segreto del Secret Manager.
GitLab / Enterprise: Devi fornire il token di accesso API e il token di accesso API di lettura che saranno memorizzati nel Secret Manager.
Una volta generata una connessione, puoi usarla per collegare i repository a cui l'account Github ha accesso.
Questa opzione è disponibile tramite il pulsante:
Nota che i repository collegati con questo metodo sono disponibili solo nei Trigger che utilizzano la 2a generazione.
Questo non è lo stesso di una connessione
. Questo consente diversi modi per ottenere accesso a un repository di Github o Bitbucket ma non genera un oggetto di connessione, ma genera un oggetto repository (di 1a generazione).
Questa opzione è disponibile tramite il pulsante:
A volte Cloud Build genera un nuovo storage per memorizzare i file per il trigger. Questo accade ad esempio nell'esempio che GCP offre con:
Un bucket di archiviazione chiamato security-devbox_cloudbuild è stato creato per memorizzare un .tgz
con i file da utilizzare.
Installa gcloud all'interno di cloud build:
Potresti trovare informazioni sensibili nelle configurazioni di build e nei log.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)