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 es una plataforma CI/CD gestionada que automáticamente construye software y procesos de lanzamiento, integrándose con repositorios de código fuente y soportando una amplia gama de lenguajes de programación. Permite a los desarrolladores construir, probar y desplegar código automáticamente mientras proporciona flexibilidad para personalizar los pasos de construcción y flujos de trabajo.
Cada Trigger de Cloud Build está relacionado con un Repositorio en la Nube o directamente conectado con un repositorio externo (Github, Bitbucket y Gitlab).
No pude ver ninguna forma de robar el token de Github/Bitbucket desde aquí o desde Repositorios en la Nube porque cuando se descarga el repo se accede a través de una URL https://source.cloud.google.com/ y Github no es accedido por el cliente.
El Cloud Build puede ser activado si:
Push a una rama: Especificar la rama
Push a una nueva etiqueta: Especificar la etiqueta
Petición de extracción: Especificar la rama que recibe la PR
Invocación Manual
Mensaje Pub/Sub: Especificar el tema
Evento Webhook: Expondrá una URL HTTPS y la solicitud debe ser autenticada con un secreto
Hay 3 opciones:
Un yaml/json especificando los comandos a ejecutar. Usualmente: /cloudbuild.yaml
Solo uno que puede ser especificado “en línea” en la consola web y en la cli
Opción más común
Relevante para acceso no autenticado
Un Dockerfile para construir
Un Buildpack para construir
La Cuenta de Servicio tiene el alcance cloud-platform
, por lo que puede usar todos los privilegios. Si no se especifica SA (como al hacer submit) se usará la SA por defecto <proj-number>@cloudbuild.gserviceaccount.com
.
Por defecto no se otorgan permisos, pero es bastante fácil otorgar algunos:
Es posible configurar un Cloud Build para requerir aprobaciones para ejecuciones de construcción (deshabilitado por defecto).
Cuando el trigger es PR porque cualquiera puede realizar PRs a repositorios públicos sería muy peligroso permitir la ejecución del trigger con cualquier PR. Por lo tanto, por defecto, la ejecución solo será automática para propietarios y colaboradores, y para ejecutar el trigger con PRs de otros usuarios, un propietario o colaborador debe comentar /gcbrun
.
Las conexiones pueden ser creadas sobre:
GitHub: Mostrará un aviso de OAuth pidiendo permisos para obtener un token de Github que será almacenado dentro del Secret Manager.
GitHub Enterprise: Pedirá instalar una GithubApp. Se creará y almacenará en este proyecto un token de autenticación de tu host de GitHub Enterprise como un secreto de Secret Manager.
GitLab / Enterprise: Necesitas proporcionar el token de acceso a la API y el token de acceso a la API de lectura que será almacenado en el Secret Manager.
Una vez que se genera una conexión, puedes usarla para vincular repositorios a los que la cuenta de Github tiene acceso.
Esta opción está disponible a través del botón:
Ten en cuenta que los repositorios conectados con este método son solo disponibles en Triggers usando la 2ª generación.
Esto no es lo mismo que una conexión
. Esto permite diferentes formas de obtener acceso a un repositorio de Github o Bitbucket pero no genera un objeto de conexión, sino que genera un objeto de repositorio (de 1ª generación).
Esta opción está disponible a través del botón:
A veces Cloud Build generará un nuevo almacenamiento para guardar los archivos para el trigger. Esto sucede, por ejemplo, en el ejemplo que GCP ofrece con:
Un bucket de almacenamiento llamado security-devbox_cloudbuild se crea para almacenar un .tgz
con los archivos que se utilizarán.
Instalar gcloud dentro de cloud build:
Podrías encontrar información sensible en las configuraciones de construcción y registros.
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)