Logo Google Cloud con Eduardo

Google Cloud con Eduardo

Recibe el código de la lección en tu correo
Te enviaremos el enlace directo al archivo (.zip) y te sumaremos a nuestra newsletter de Google Cloud.

Información básica de protección de datos: Responsable: Eduardo Martínez Agrelo. Finalidad: Facilitar el recurso solicitado y enviar comunicaciones periódicas de valor sobre Google Cloud. Legitimación: Consentimiento del interesado (Art. 6.1.a RGPD). Destinatarios: Plataforma Odoo y proveedores de infraestructura técnica (Google Cloud / Firebase). Derechos: Acceso, rectificación y supresión en eduardomartinezagrelo@gmail.com.
✦ Guía Técnica & Arquitectura Enterprise

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.

✓
Private Worker Pools

Aislamiento en VPC propia con acceso a recursos internos sin IP pública.

✓
Supply Chain Security

SLSA Nivel 3, atestaciones firmadas con Cloud KMS y Binary Authorization.

✓
Optimización FinOps

Caché distribuida con Kaniko, paralelización de pasos y dimensionamiento justo.

✓
Pipelines Declarativos

Estructuración modular de cloudbuild.yaml para CI/CD multi-entorno.

GCP Cloud Build Private Pools Artifact Registry Cloud KMS Binary Authorization Terraform SLSA Level 3 VPC Peering

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.
Antipatrón Crítico: Descarga de Dependencias en Cada Build y Omisión de Caché

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.

cloudbuild.yaml — Pipeline CI/CD Seguro YAML
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:

  1. Aprovisionamiento de Repositorios Seguros en Artifact Registry

    Configura repositorios regionales Docker/Maven/NPM con análisis continuo de vulnerabilidades automático (Container Analysis) activado.

  2. 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.

  3. 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.

  4. 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 includedFiles para compilar únicamente los microservicios modificados.

  5. 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.

Sobre el Autor: Eduardo Martínez Agrelo

AI & Data Architect

Especialista en el diseño e implementación de arquitecturas cloud a gran escala, plataformas de datos distribuidas y sistemas de inteligencia artificial en producción. Con foco en la seguridad de supply chain, observabilidad avanzada y eficiencia de costes (FinOps) en ecosistemas multicloud.