Skip to content

GCP DevOps (Cloud Build, Cloud Deploy, Artifact Registry, Binary Authorization)

Scope

CI/CD pipelines (Cloud Build, Cloud Build v2, Cloud Deploy), artifact management (Artifact Registry), supply chain security (Binary Authorization, Software Delivery Shield), source code management (Secure Source Manager), deployment strategies.

Checklist

  • [Critical] Configure Cloud Build triggers for CI automation: repository event triggers (push to branch, tag creation, pull request) from GitHub, GitLab, or Bitbucket via Cloud Build v2 connections; use trigger filters (branch name regex, file path filters, invert filters) to control which changes trigger builds
  • [Recommended] Design Cloud Build configuration (cloudbuild.yaml) with build steps: each step runs in a specified container image, steps execute sequentially by default or in parallel with waitFor directives; use substitution variables for parameterization and built-in substitutions ($COMMIT_SHA, $BRANCH_NAME, $TAG_NAME)
  • [Recommended] Set up Cloud Build worker pools for private networking: default workers run on Google-managed infrastructure with public internet access; private worker pools run in a customer VPC for access to private resources (Cloud SQL, Memorystore, internal APIs) and compliance requirements (no public IP); configure machine type (e2, n1) and disk size per pool
  • [Recommended] Configure Cloud Deploy delivery pipelines for CD: define pipeline stages (dev -> staging -> production) with targets (GKE clusters, Cloud Run services, GKE Enterprise clusters); each target specifies execution environment, deployment strategy, and approval requirements; Cloud Deploy manages release promotion across stages
  • [Recommended] Implement Cloud Deploy deployment strategies: standard (replace all instances), canary (percentage-based rollout with customizable phases, e.g., 10% -> 50% -> 100%, with verification between phases), and custom (user-defined deployment and verification steps via Skaffold); configure automatic rollback on canary verification failure
  • [Critical] Set up Artifact Registry for container images and packages: Docker repositories (container images), language-specific repositories (npm, Maven, Python, Go, apt, yum), and remote repositories (proxy and cache public registries like Docker Hub, npm, Maven Central); supports multi-region repositories for geo-redundant storage
  • [Recommended] Enable Binary Authorization for supply chain security: require container images to have attestations (signed by trusted attestors) before deployment to GKE or Cloud Run; integrate with Cloud Build (automatic attestation after successful build and vulnerability scanning); block unsigned or unverified images in production
  • [Recommended] Configure vulnerability scanning in Artifact Registry: automatic scanning on push (Container Analysis API), severity-based policies (block deployment of images with CRITICAL vulnerabilities), integration with Binary Authorization (attestation only after scan passes); on-demand scanning for existing images
  • [Recommended] Design Cloud Build service account permissions: default Cloud Build service account has broad permissions; create custom service accounts per build trigger with least-privilege IAM roles; use Workload Identity Federation for builds needing access to external resources
  • [Optional] Implement build caching strategies: use kaniko cache for Docker layer caching (--cache=true with Artifact Registry cache repository), Cloud Storage-based caching for build artifacts (download at start, upload at end), and Cloud Build's built-in cache volumes for multi-step builds
  • [Recommended] Use Secure Source Manager or external Git hosting: Cloud Source Repositories reached end-of-sale (June 2024) and is not recommended for new projects; Secure Source Manager provides managed Git hosting with built-in security (vulnerability scanning, access controls, audit logging); alternatively integrate with GitHub or GitLab via Cloud Build v2 repository connections
  • [Recommended] Configure deployment approvals and automation: Cloud Deploy release promotion requires manual approval for production targets (configurable approvers); Cloud Build triggers can gate on approval via manual triggers; integrate with Cloud Monitoring for deployment health signals and automatic rollback
  • [Recommended] Evaluate Software Delivery Shield for end-to-end supply chain security: provides a unified view of software supply chain security posture across build, deploy, and runtime; integrates SLSA compliance levels, vulnerability scanning, Binary Authorization, and runtime security insights in a single dashboard
  • [Recommended] Use Cloud Build v2 for new projects: Cloud Build v2 provides native GitHub and GitLab connections (replacing mirroring), improved trigger configuration, and Tekton-based build pipeline support; offers better integration with modern Git workflows including PR-based triggers with build status checks

Why This Matters

GCP's CI/CD services are designed to work together as an integrated delivery platform: Cloud Build compiles and tests code, Artifact Registry stores versioned artifacts, Binary Authorization enforces supply chain policies, and Cloud Deploy manages progressive delivery across environments. Software Delivery Shield adds an overarching security posture view across the entire pipeline. Each component can be used independently, but the integrated pipeline provides end-to-end traceability from commit to production with security verification at each stage.

Cloud Build pricing is based on build minutes with a free tier (120 minutes/day on default workers). Private worker pools cost more ($0.049/build-minute for e2-medium) but provide VPC access and custom machine types. Build optimization (caching, parallel steps, efficient Docker layers) directly impacts both cost and developer feedback loop speed.

Cloud Source Repositories reached end-of-sale in June 2024. New projects should use Secure Source Manager (Google-managed Git with security features) or external providers (GitHub, GitLab) with Cloud Build v2 connections. Existing Cloud Source Repositories users should plan migration.

Binary Authorization is increasingly important for compliance frameworks (FedRAMP, SOC 2, PCI-DSS) that require provenance verification for deployed software. Without Binary Authorization, any image pushed to Artifact Registry can be deployed to production. With it, only images that passed CI, vulnerability scanning, and explicit attestation can run in production clusters.

Cloud Deploy's canary deployment with verification represents a significant maturity improvement over manual deployment approval gates. Instead of a human visually checking dashboards after deployment, Cloud Deploy can automatically verify deployment health using Cloud Monitoring metrics, run integration test suites, and roll back if verification fails -- all within the deployment pipeline.

Common Decisions (ADR Triggers)

  • Cloud Build vs Jenkins/GitLab CI/GitHub Actions -- Cloud Build is GCP-native with deep IAM integration, private worker pools for VPC access, and no infrastructure to manage. Jenkins provides maximum flexibility and plugin ecosystem but requires self-management. GitLab CI integrates tightly with GitLab repositories. GitHub Actions integrates with GitHub and has a large marketplace. Use Cloud Build for GCP-centric teams wanting managed CI with VPC access. Use GitHub Actions for GitHub-native workflows. Use Jenkins only for complex existing pipelines that are difficult to migrate.
  • Cloud Deploy vs Spinnaker vs Argo CD -- Cloud Deploy is managed, integrates with Cloud Build and GKE, and supports canary with verification out of the box. Spinnaker is powerful but operationally heavy (requires its own infrastructure and expertise). Argo CD provides GitOps-based deployment for Kubernetes with declarative configuration. Use Cloud Deploy for GKE and Cloud Run deployments wanting managed progressive delivery. Use Argo CD for GitOps model with pull-based deployment. Use Spinnaker for multi-cloud or very complex deployment pipelines.
  • Artifact Registry vs Container Registry -- Container Registry (gcr.io) is the legacy service built on Cloud Storage buckets. Artifact Registry is the recommended replacement supporting Docker, language packages (npm, Maven, Python), and remote repositories. Artifact Registry provides fine-grained IAM, vulnerability scanning, regional/multi-region repositories, and cleanup policies. All new projects should use Artifact Registry. Migrate existing Container Registry usage via automatic redirection.
  • Default vs private worker pools -- Default worker pools run on Google-managed infrastructure with no VPC access, standard machine types, and public internet access. Private pools run in customer VPC, support custom machine types (up to 32 vCPU), and can access private resources. Use default pools for standard builds that do not need private network access. Use private pools for builds requiring VPC access (private dependencies, database migrations, integration tests against private services) or specific compliance requirements.
  • Binary Authorization enforce vs dry-run -- Enforce mode blocks non-attested images from deploying (hard failure). Dry-run mode logs violations without blocking deployment. Start with dry-run to identify images that would be blocked, create attestation workflows, then switch to enforce. Use break-glass mechanism (emergency override with audit logging) for production hotfix scenarios that cannot wait for the full attestation pipeline.
  • Monorepo vs polyrepo Cloud Build triggers -- Monorepo uses included/excluded file filters on triggers (trigger only when files in specific directories change) with multiple cloudbuild.yaml files per subdirectory. Polyrepo uses one trigger per repository with simpler configuration. Monorepo provides atomic cross-service changes and simpler dependency management. Polyrepo provides independent build and release cycles per service. Use monorepo for tightly coupled services. Use polyrepo for independently deployable microservices.
  • Source code hosting -- Secure Source Manager (Google-managed, built-in security scanning) vs GitHub (largest ecosystem, Actions integration) vs GitLab (built-in CI/CD, self-hosted option). Cloud Source Repositories is end-of-sale and should not be used for new projects.

Reference Architectures

Secure CI/CD Pipeline with Binary Authorization

GitHub repository -> Cloud Build v2 trigger (on push to main): (1) run unit tests, (2) build Docker image with kaniko (cached layers in Artifact Registry), (3) push image to Artifact Registry, (4) Container Analysis vulnerability scan, (5) if no CRITICAL vulnerabilities, create Binary Authorization attestation (signed by Cloud KMS key), (6) update Cloud Deploy release manifest. Cloud Deploy pipeline: dev target (auto-promote) -> staging target (auto-promote after smoke tests) -> production target (manual approval + Binary Authorization enforcement). GKE clusters configured with Binary Authorization policy requiring attestation from build-attestor. Software Delivery Shield dashboard provides unified view of supply chain security posture.

Multi-Environment Cloud Run Delivery

Cloud Build v2 trigger on tag push (v*) -> build container, push to Artifact Registry (multi-region us), create Cloud Deploy release. Cloud Deploy pipeline: dev (Cloud Run in us-central1, auto-promote) -> staging (Cloud Run in us-central1, canary 25% -> 50% -> 100% with Cloud Monitoring verification: error rate < 1%, p99 latency < 500ms) -> production (Cloud Run in us-central1, manual approval, canary 10% -> 50% -> 100%). Automatic rollback if canary verification fails. Cloud Monitoring dashboard per release showing deployment progress and health metrics.

GitOps with Config Sync and Cloud Build

Application CI: Cloud Build builds image, pushes to Artifact Registry, opens PR to config repository updating image tag in Kustomize overlay. Config repository: reviewed and merged by team. Config Sync on GKE clusters watches config repository and reconciles cluster state. Cloud Build validation trigger on config PR: runs kubeval/kubeconform, policy checks (Gatekeeper/OPA), and dry-run apply. Binary Authorization ensures only images from the trusted Artifact Registry repository are deployed. Drift detection alerts when cluster state diverges from Git.

Private Build Environment with VPC Access

Cloud Build private worker pool in shared VPC (10.0.0.0/24 subnet). Build steps access private Cloud SQL instance for database migration (Flyway/Liquibase), private Memorystore for integration test cache, and internal npm registry hosted on Compute Engine. Artifact Registry in same region for low-latency image push. Build artifacts cached in Cloud Storage bucket (private, same VPC). Custom build images stored in Artifact Registry with pre-installed tooling (Terraform, Helm, custom CLIs). IAM: custom service account per trigger with minimum required roles.

See Also

  • general/ci-cd.md -- general CI/CD pipeline patterns
  • providers/gcp/containers.md -- GKE and Artifact Registry integration
  • providers/gcp/security.md -- Binary Authorization and supply chain security