Google Cloud Build: CI/CD Serverless, Redes Privadas y Seguridad en Supply Chain
Diseña pipelines de integración y entrega continua altamente resilientes, gobernados y optimizados en costes sobre Google Cloud. De la configuración serverless a Private Pools con VPC Peering y verificación criptográfica SLSA.
Aislamiento en VPC propia con acceso a recursos internos sin IP pública.
SLSA Nivel 3, atestaciones firmadas con Cloud KMS y Binary Authorization.
Caché distribuida con Kaniko, paralelización de pasos y dimensionamiento justo.
Estructuración modular de cloudbuild.yaml para CI/CD multi-entorno.
Matriz de Selección: Default Pool vs. Private Worker Pools
Elegir el modelo de ejecución adecuado en Cloud Build determina el nivel de seguridad de la red, los costes operativos y la capacidad de interactuar con clusters privados o bases de datos no expuestas.
| Parámetro Arquitectónico | Default Shared Pool (Serverless) | Private Worker Pools (VPC Dedicada) |
|---|---|---|
| Aislamiento de Red | Multi-tenant gestionado por Google, salida pública dinámica. | Single-tenant en VPC propia vía Service Networking Connection. |
| Acceso a Recursos Privados | Requiere exponer endpoints a internet con autenticación IAM/IAP. | Conexión nativa por IP privada a Cloud SQL, GKE privado y VMs. |
| Capacidad de Cómputo | Limitado a tipos de máquina predefinidos (hasta 32 vCPUs). | Configurable hasta 128 vCPUs, soporte GPU y discos NVMe locales. |
| Salida de Red Estática (Egress) | No configurable (rango dinámico de IPs públicas de GCP). | Soportada mediante Cloud NAT o Cloud VPN/Interconnect. |
| Modelo de Costes | Pago por segundo exacto de compilación ejecutada. | Pago por tiempo de ejecución de workers + tarifa horaria de aprovisionamiento. |
| Caso de Uso Típico | Microservicios desacoplados, builds rápidos, testing unitario ligero. | Empresas reguladas, builds masivos (C++, Java, LLM fine-tuning), acceso a VPC. |
Uno de los errores más costosos en pipelines de Cloud Build es ejecutar docker build estándar sin capas intermedias cacheadas en Artifact Registry. Esto genera descargas repetitivas de gigabytes en dependencias de Maven, NPM, PyPI o capas base de Linux, multiplicando por 4 el tiempo de ejecución y el coste de cómputo. La solución de nivel arquitectónico es sustituir el builder tradicional por el executor Kaniko con volcado de capas remotas o emplear BuildKit con backend de caché desacoplado.
Pipeline de Producción Multi-Stage con Kaniko y Binary Authorization
El siguiente manifiesto cloudbuild.yaml define un pipeline optimizado: utiliza Kaniko para compilar y cachear capas en Artifact Registry, ejecuta escaneo de seguridad SAST/SCA y firma la atestación para Binary Authorization antes del despliegue en un entorno productivo de Cloud Run o GKE.
steps:
# Paso 1: Pruebas unitarias y análisis estático con persistencia de entorno
- name: 'python:3.11-slim'
entrypoint: '/bin/sh'
args:
- '-c'
- |
pip install --no-cache-dir pytest flake8
flake8 src/
pytest tests/
id: 'unit-tests'
# Paso 2: Compilación de alta velocidad y push con Kaniko Cache habilitado
- name: 'gcr.io/kaniko-project/executor:latest'
args:
- '--destination=${_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${_REPO_NAME}/app:${SHORT_SHA}'
- '--destination=${_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${_REPO_NAME}/app:latest'
- '--cache=true'
- '--cache-ttl=168h'
- '--cache-dir=/workspace/.kaniko-cache'
id: 'kaniko-build-push'
waitFor: ['unit-tests']
# Paso 3: Firma de Atestación criptográfica mediante Cloud KMS para Binary Authorization
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk:slim'
entrypoint: '/bin/bash'
args:
- '-c'
- |
DIGEST=$(gcloud artifacts docker images describe \
${_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${_REPO_NAME}/app:${SHORT_SHA} \
--format='get(image_summary.digest)')
gcloud beta container binauthz attestations sign-and-create \
--artifact-url="${_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${_REPO_NAME}/app@${DIGEST}" \
--attestor="${_ATTESTOR_NAME}" \
--attestor-project="${PROJECT_ID}" \
--keyversion-project="${PROJECT_ID}" \
--keyversion-location="${_KMS_LOCATION}" \
--keyversion-keyring="${_KMS_KEYRING}" \
--keyversion-key="${_KMS_KEY}" \
--keyversion="1"
id: 'sign-binary-authorization'
waitFor: ['kaniko-build-push']
# Paso 4: Despliegue continuo hacia Cloud Run verificando la imagen autenticada
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk:slim'
entrypoint: 'gcloud'
args:
- 'run'
- 'deploy'
- '${_SERVICE_NAME}'
- '--image=${_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${_REPO_NAME}/app:${SHORT_SHA}'
- '--region=${_LOCATION}'
- '--platform=managed'
- '--binary-authorization=default'
id: 'deploy-cloud-run'
waitFor: ['sign-binary-authorization']
substitutions:
_LOCATION: 'europe-west1'
_REPO_NAME: 'production-containers'
_SERVICE_NAME: 'payments-core-api'
_ATTESTOR_NAME: 'quality-gate-attestor'
_KMS_LOCATION: 'europe-west1'
_KMS_KEYRING: 'binauthz-keyring'
_KMS_KEY: 'attestor-signer'
options:
logging: CLOUD_LOGGING_ONLY
machineType: 'E2_HIGHCPU_8'
Patrones de Diseño y Buenas Prácticas de Gobernanza
En despliegues de grado corporativo, la configuración de Cloud Build debe ajustarse bajo principios estrictos de seguridad de identidad y resiliencia.
Principle of Least Privilege (PoLP)
Desactiva la cuenta de servicio por defecto ([PROJECT_NUMBER]@cloudbuild.gserviceaccount.com) y asigna Service Accounts personalizadas por cada pipeline con roles granulares mínimos (ej. roles/artifactregistry.writer o roles/run.developer).
Inmutabilidad mediante Tags y Digests
Evita basar los despliegues únicamente en el tag latest. Utiliza siempre el SHA-256 inmutable (image@sha256:...) para garantizar trazabilidad absoluta e impedir ataques de sobreescritura de imágenes.
Auditoría con Cloud Logging
Configura la opción logging: CLOUD_LOGGING_ONLY o redirige logs a buckets cifrados en Cloud Storage con políticas de retención WORM (Write Once, Read Many) para cumplir con auditorías PCI-DSS e ISO 27001.
Framework de Adopción Empresarial en 5 Pasos
Hoja de ruta para migrar de pipelines dispersos a una plataforma unificada y segura con Google Cloud Build:
-
Aprovisionamiento de Repositorios Seguros en Artifact Registry
Configura repositorios regionales Docker/Maven/NPM con análisis continuo de vulnerabilidades automático (Container Analysis) activado.
-
Configuración de VPC Peering y Worker Pools Privados
Reserva un bloque CIDR dedicado en la red VPC y establece el enlace con el productor de servicios (Service Networking API) para aislar el tráfico de compilación.
-
Integración de Repositorios con Cloud Build Repositories (2nd Gen)
Conecta GitHub, GitLab o Bitbucket mediante conexiones seguras cifradas con Secret Manager y autenticación basada en tokens de granularidad fina.
-
Definición de Triggers con Estrategias de Rama y Filtro de Rutas
Crea Cloud Build Triggers activados por pull requests o merges a ramas maestras, utilizando directivas
includedFilespara compilar únicamente los microservicios modificados. -
Imposición de Políticas de Binary Authorization
Bloquea en tus clusters de Kubernetes y servicios serverless cualquier contenedor que no cuente con la firma criptográfica generada en el paso final del pipeline verificado.
Preguntas Frecuentes (FAQ)
¿Cuándo es obligatorio utilizar Cloud Build Private Pools en lugar del pool por defecto?
Los Private Pools son requeridos cuando el pipeline necesita acceder a recursos con IPs privadas dentro de una VPC de GCP (como GKE privado, Cloud SQL o VMs internas) mediante VPC Network Peering, cuando la gobernanza exige egress con IP estática mediante Cloud NAT, o cuando se demandan especificaciones de máquina de alto cómputo (hasta 128 vCPUs) y soporte para aceleración GPU.
¿Cómo optimizar drásticamente los tiempos de compilación de imágenes Docker en Cloud Build?
La técnica principal consiste en implementar Kaniko con el flag --cache=true apuntando a un repositorio dedicado en Artifact Registry, complementado con el uso de BuildKit (--export-cache y --import-cache) y el montaje de volúmenes persistentes entre pasos dentro de los steps del cloudbuild.yaml.
¿Cómo se garantiza el cumplimiento de Supply-Chain Levels for Software Artifacts (SLSA) con Cloud Build?
Cloud Build soporta la generación automática de procedencia no falsificable (SLSA Level 3). Al activar Binary Authorization en GCP, solo las imágenes firmadas criptográficamente por la cuenta de servicio de attestations de Cloud Build y verificadas contra la política de KMS pueden ser desplegadas en entornos de Cloud Run o GKE.
