Imagine la situación: ha configurado la compilación y el despliegue automáticos de una aplicación mediante Google Cloud Build, todo funciona a la perfección, el código se compila automáticamente con cada commit. Pero, ¿y si le digo que esa misma automatización puede convertirse en un punto de entrada para un atacante que obtenga control total sobre su infraestructura? Hoy analizaremos una de las vulnerabilidades más subestimadas en los sistemas CI/CD en la nube: la ejecución remota de código (RCE) por una mala configuración de Cloud Build.
¿Qué es Cloud Build y por qué es importante
Google Cloud Build es un servicio gestionado para integración continua y entrega continua que permite automatizar el proceso de compilación, pruebas y despliegue de aplicaciones. Suena conveniente, ¿no? Usted envía código al repositorio, Cloud Build detecta los cambios, ejecuta la compilación según las instrucciones definidas y despliega el resultado. Todo ocurre sin su intervención.
El problema comienza donde termina la comprensión de cómo funciona exactamente este mecanismo. Cloud Build ejecuta comandos con privilegios bastante elevados, ya que necesita compilar imágenes Docker, desplegar en Kubernetes y acceder a diversos servicios de GCP. Si la configuración es incorrecta, esos privilegios pueden convertirse en un arma en manos de un atacante.
La característica clave de Cloud Build es que utiliza un archivo de configuración (normalmente cloudbuild.yaml o cloudbuild.json) que describe los pasos de compilación. Este archivo suele almacenarse directamente en el repositorio de código, lo que crea una situación interesante: cualquiera que pueda modificar ese archivo puede potencialmente ejecutar comandos arbitrarios en el contexto de la compilación.
Anatomía de la vulnerabilidad: cómo se produce la explotación
Analicemos un escenario típico de ataque. Supongamos que tenemos un repositorio público en GitHub conectado a Cloud Build mediante un desencadenador. Cada solicitud de extracción se ejecuta automáticamente para comprobar el código. Suena como una práctica estándar que usan miles de proyectos.
El atacante crea una solicitud de extracción con cambios aparentemente inocuos en el código, pero también modifica el archivo cloudbuild.yaml. En lugar de comandos normales de compilación añade pasos como extraer secretos del entorno o instalar una puerta trasera. Dado que Cloud Build ejecuta las instrucciones del archivo de configuración que llega con la solicitud de extracción, todos esos comandos se ejecutarán.
Principales vectores de ataque
-
Extracción de variables de entorno y secretos. Cloud Build suele tener acceso a claves API, tokens de autenticación y otros datos sensibles a través de variables de entorno o del servicio Secret Manager. El atacante puede simplemente volcarlos en los registros de compilación o enviarlos a un servidor externo.
-
Movimiento lateral en la infraestructura en la nube. Utilizando la cuenta de servicio con la que se ejecuta Cloud Build, el atacante puede acceder a otros recursos de GCP: bases de datos, buckets de almacenamiento, instancias de cómputo.
-
Sustitución de artefactos de compilación. En lugar de la aplicación legítima se puede compilar y desplegar una versión modificada con una puerta trasera, que desde el exterior parecerá totalmente normal.
-
Criptominería y uso de recursos. Clásico: aprovechar la capacidad de cómputo para minar criptomonedas u otras tareas intensivas en recursos a costa de terceros.
Ejemplos reales de explotación
Veamos un ejemplo concreto. Una empresa tiene arquitectura de microservicios, cada servicio en un repositorio separado en GitHub. Para facilitar el trabajo de los desarrolladores se ha configurado un desencadenador de Cloud Build que se activa en cada solicitud de extracción para ejecutar pruebas. La configuración es más o menos así:
En el archivo cloudbuild.yaml están los pasos estándar: instalar dependencias, ejecutar pruebas, construir la imagen Docker. Pero, ¿qué ocurre si un atacante modifica ese archivo en su solicitud de extracción? Puede añadir un paso que parezca parte del proceso de pruebas, pero que en realidad ejecute acciones maliciosas.
Por ejemplo, añadir un paso aparentemente inofensivo de "comprobación de configuración" puede en realidad extraer todos los secretos accesibles del Secret Manager de GCP y enviarlos a un servidor controlado por el atacante. O la instalación de "herramientas adicionales de prueba" puede ser la instalación de un shell inverso para obtener acceso interactivo al entorno de compilación.
Las situaciones son especialmente peligrosas cuando Cloud Build está configurado con permisos excesivamente amplios. Si la cuenta de servicio tiene el rol Editor u Owner a nivel de proyecto, el atacante obtiene capacidades prácticamente ilimitadas para manipular la infraestructura.
Técnicas para detectar una configuración vulnerable
¿Cómo saber si su configuración de Cloud Build es vulnerable? Hay varios indicios clave a los que prestar atención.
Indicadores potenciales de vulnerabilidad
-
Activación automática de compilaciones para solicitudes de extracción externas. Si el desencadenador de Cloud Build está configurado para ejecutarse en pull requests de cualquier usuario sin aprobación manual, es una primera señal de alerta.
-
Uso del archivo de configuración desde la solicitud de extracción. Verifique de dónde toma Cloud Build las instrucciones de compilación. Si usa el archivo incluido en la propia solicitud de extracción en lugar de uno en una rama protegida, hay un problema.
-
Permisos amplios en la cuenta de servicio. Revise los roles IAM asignados a la cuenta de servicio de Cloud Build. Si incluye roles de nivel Editor, Owner o roles específicos con amplios permisos, conviene revisarlos.
-
Falta de aislamiento entre proyectos. Si una misma cuenta de servicio de Cloud Build se utiliza para compilar múltiples proyectos con distintos niveles de criticidad, existe el riesgo de comprometer sistemas más sensibles a través de los menos protegidos.
Métodos de protección y configuración correcta
Protegerse contra RCE por una mala configuración de Cloud Build requiere un enfoque integral. No basta con limitar los permisos de la cuenta de servicio: hay que revisar todo el proceso CI/CD desde la perspectiva de la seguridad.
Recomendaciones prácticas de protección
Use aprobación manual para solicitudes de extracción externas. Configure Cloud Build de modo que las compilaciones para solicitudes de extracción de contribuyentes externos requieran la aprobación explícita de un mantenedor del proyecto. Esto se puede gestionar mediante reglas en GitHub Actions o en GitLab CI/CD que desencadenen Cloud Build solo después de una revisión.
Almacene la configuración de compilación por separado. En lugar de usar cloudbuild.yaml desde la solicitud de extracción, guarde la configuración de referencia en una rama protegida o fuera del repositorio. Cloud Build admite configuraciones en línea directamente en el desencadenador: utilice esa opción.
Aplicar el principio de mínimos privilegios. Cree cuentas de servicio separadas para las distintas fases de la compilación con los permisos estrictamente necesarios. Por ejemplo, la cuenta que ejecuta las pruebas no debe tener acceso a secretos de producción ni capacidad de despliegue.
Use sustituciones en lugar de acceso directo a secretos. Cloud Build soporta variables de sustitución, que permiten pasar datos sensibles sin exponerlos en los registros o en la configuración.
Configure auditoría y monitorización. Active Cloud Audit Logs para todas las operaciones de Cloud Build y configure alertas ante actividad sospechosa: comandos inusuales en los registros de compilación, acceso a recursos atípicos, cambios en las políticas IAM.
Aísle los entornos de compilación. Utilice proyectos GCP separados para cada etapa: un proyecto para CI/CD, otro para staging y otro para producción. Esto limitará el daño potencial en caso de compromiso.
Herramientas para auditar la seguridad de Cloud Build
Existen varias herramientas útiles que ayudan a detectar problemas de configuración de Cloud Build y otros aspectos de seguridad en GCP.
-
Forseti Security — una herramienta integral para auditar la seguridad en GCP, capaz de identificar permisos IAM excesivos y configuraciones incorrectas.
-
ScoutSuite — herramienta de auditoría de seguridad multi-nube, con soporte para GCP y capacidad para encontrar errores de configuración en distintos servicios.
-
GCP IAM Privilege Escalation — conjunto de scripts para localizar rutas de escalada de privilegios mediante IAM, útil para entender el nivel real de acceso de las cuentas de servicio.
Enfoques alternativos para organizar CI/CD
A veces la mejor solución es replantear la arquitectura del pipeline CI/CD por completo. En lugar de dar a Cloud Build acceso directo a recursos críticos, pueden aplicarse patrones más seguros.
Una aproximación consiste en utilizar un entorno de compilación independiente y aislado y luego firmar los artefactos. Cloud Build compila la aplicación en un entorno aislado sin acceso a recursos de producción, crea una imagen firmada que después es verificada y desplegada por un proceso separado con más privilegios.
Otra opción es usar Binary Authorization junto con Cloud Build. Este servicio permite establecer políticas que definan qué imágenes pueden desplegarse en su clúster de Kubernetes, basadas en firmas criptográficas y metadatos del proceso de compilación.
También conviene considerar soluciones gestionadas de CI/CD con control de acceso más granular, como GitLab CI con entornos protegidos o GitHub Actions con reglas de protección de entornos.
Conclusión: la seguridad como proceso, no como estado
La RCE por una mala configuración de Cloud Build no es solo una vulnerabilidad técnica; es un síntoma de un problema más profundo: la falta de atención a la seguridad en el proceso de automatización. Nos apresuramos tanto en acelerar el desarrollo y el despliegue que a veces olvidamos los principios básicos de security by design.
Es importante entender que una configuración segura de Cloud Build no es una tarea puntual, sino un proceso continuo. Las amenazas evolucionan, aparecen nuevos vectores de ataque y cambian las mejores prácticas. La auditoría periódica de configuraciones, la actualización de políticas de seguridad y la formación del equipo deben formar parte de la cultura DevSecOps.
Recuerde: cada elemento de la automatización es una posible puerta de entrada para un atacante. Pero eso no significa renunciar a la automatización. Significa abordarla con consciencia, con comprensión de los riesgos y con medidas para minimizarlos. Cloud Build es una herramienta potente que puede acelerar mucho su desarrollo, pero también puede ser la causa de un incidente grave. La elección es suya.
