Chapter 25

Secure Deployment

Scope. This chapter owns deployment: Cloud Deploy pipelines and targets, promotion and approval, the GKE and Cloud Run surfaces, canary and blue/green, rollback, the deploy-time policy gate, image signing, provenance verification, and the separation of build and deploy identities. Building is Chapter 23 and artifact storage is Chapter 24. §9.27 owns Binary Authorization as GKE consumes it; Chapter 37 owns attestation authoring and attestor design. §8.11 cites this chapter for managed instance group rollouts. Prerequisites. Chapter 9 (§9.27 Binary Authorization on GKE), Chapter 10 (Cloud Run), Chapter 23 (§23.13 provenance), Chapter 24 (§24.7 promotion). Verified against. Google Cloud console and API surface as of 2026-09, Cloud SDK 583.0.0, hashicorp/google provider 8.x; see sources at end.

Deployment is the last place a control can act, and it is the only place where every earlier control's output is available at once: a source revision that was reviewed, an artifact that was scanned, provenance that says how it was built, and an environment that has its own rules about what may run in it. A deployment gate that checks nothing wastes that, and most of them check nothing — they check that a pipeline stage succeeded, which is a statement about the pipeline rather than about the artifact.

The chapter's organizing claim is that a secure deployment has three separations. The identity that builds is not the identity that deploys (§25.13), so a compromised build cannot ship. The artifact is referenced by digest, not by tag (§25.12), so what was verified is what runs. And production requires something a pipeline cannot supply on its own — a human approval, a policy evaluation, or a time window (§25.4, §25.10, §25.14).

Cloud Deploy is the product that makes these practical, because it models promotion between environments as a first-class object with per-target identities and per-target approval. It is not the only way — a Cloud Build pipeline that deploys directly works — but the identity separation is something you then have to build by hand, and it is the part teams skip.

25.1 Cloud Deploy §

Cloud Deploy is a managed continuous delivery service that renders a release once and promotes the same rendered output through a series of targets.

Five resources make up the model:

Configuration is declarative and applied from a file:

gcloud deploy apply --file=clouddeploy.yaml --region=us-central1

The rendering happens once, at release creation. gcloud deploy releases create resolves images and renders manifests for every target in the pipeline up front, which is what makes promotion a deployment of something already reviewed rather than a fresh build per environment.

Execution runs as an identity you choose per target. A target's executionConfigs block names usages — RENDER, PREDEPLOY, DEPLOY, VERIFY, POSTDEPLOY, ANALYSIS — plus a serviceAccount and optionally a workerPool. That is the mechanism behind §25.13: production's deploy identity is different from staging's, and both differ from the build's.

Pitfall. Cloud Deploy renders with Skaffold, so a manifest that resolves configuration at deploy time — a Helm value from a live lookup, an environment variable read from the cluster — is not captured in the release. What was reviewed and what runs then differ, which is exactly the gap the render step exists to close.

25.2 Delivery Pipelines §

A delivery pipeline is an ordered list of stages, each naming a target and, optionally, a strategy and a set of Skaffold profiles.

apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
  name: dp-billing
description: Billing service delivery pipeline.
serialPipeline:
  stages:
    - targetId: dev
      profiles: [dev]
    - targetId: stg
      profiles: [stg]
    - targetId: prod
      profiles: [prod]
      strategy:
        canary:
          runtimeConfig:
            cloudRun:
              automaticTrafficControl: true
          canaryDeployment:
            percentages: [10, 50]
            verify: true

profiles takes "a list of zero or more Skaffold profile names", which is how one release renders differently per environment without becoming a different artifact. Profiles change configuration; they must not change the image.

Model the pipeline on the trust boundaries, not on the team structure. Every stage transition is an opportunity to require evidence, so a pipeline with dev → stg → prod has two gates and a pipeline with one stage has none.

One pipeline per deployable unit. A pipeline that deploys three services together couples their release cadence and makes a rollback of one a rollback of all.

Pitfall. serialPipeline is serial by name and by behavior — a release must reach a target before it can be promoted past it. Teams that want to deploy to two regions simultaneously reach for two pipelines; the intended mechanism is a multiTarget (§25.5), and using two pipelines means two independent release histories for one service.

25.3 Promotion §

Promotion moves a release from one target to the next. In Cloud Deploy it deploys an already-rendered artifact, which is what makes it meaningfully different from redeploying.

gcloud deploy releases create billing-1-4-2 \
  --delivery-pipeline=dp-billing \
  --region=us-central1 \
  --images=billing=us-central1-docker.pkg.dev/rc-saas-shared-art-01/\
prod-docker/billing@sha256:DIGEST \
  --description="Billing 1.4.2"

gcloud deploy releases promote \
  --release=billing-1-4-2 \
  --delivery-pipeline=dp-billing \
  --region=us-central1 \
  --to-target=prod

Pass --images with a digest, not a tag. The release records exactly what will run at every stage, and a tag resolved at release time is at least recorded — but a digest is what makes the record verifiable later against provenance (§25.12) and against the immutable tag in the registry (§24.5).

Promotion is the artifact's audit trail. Each rollout records the release, the target, the actor, and the time, in Admin Activity logs (§17.2). "Which build is in production, and who put it there" is a query rather than an archaeology exercise.

Never skip a stage. --to-target can jump ahead, and there are legitimate emergencies for it, but each skipped stage is a gate that did not run. Log the skip explicitly and treat it as a break-glass event (§25.14).

Pitfall. Promoting a release whose lower-environment rollout failed is possible and is occasionally what someone does under pressure. Deploy policies (§25.14) are the mechanism to prevent it; without one, the pipeline's order is a convention.

25.4 Approval Gates §

An approval gate pauses a rollout until a human approves it. In Cloud Deploy it is one boolean on a target.

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: prod
description: Production Cloud Run target.
requireApproval: true
run:
  location: projects/rc-saas-prod-app-01/locations/us-central1
executionConfigs:
  - usages: [RENDER, PREDEPLOY, DEPLOY, VERIFY, POSTDEPLOY]
    serviceAccount: sa-deploy-prod@rc-saas-shared-cicd-01.iam.gserviceaccount.com

requireApproval defaults to false, so a target without the field deploys automatically. Set it explicitly on production even when the default would be right, because an explicit false elsewhere documents that the choice was made.

Approval is a distinct IAM role. roles/clouddeploy.approver grants the ability to approve a rollout without granting the ability to create releases or modify pipelines. Grant it to a group that includes people who did not write the change.

gcloud deploy rollouts approve ROLLOUT_ID \
  --delivery-pipeline=dp-billing \
  --release=billing-1-4-2 \
  --region=us-central1

An approval that is always granted is not a gate. Give the approver something to evaluate: the release description, the diff since the last production release, the verification results, and the vulnerability delta. An approval prompt with none of that trains people to click.

Pitfall. Approval gates create pressure to approve during incidents, and the pressure is legitimate — a fix cannot ship. Provide the break-glass path in advance (--override-deploy-policies, an emergency approver group) with alerting attached, rather than letting someone discover that removing requireApproval from the target is faster.

25.5 GKE Deployment §

A GKE target names a cluster, and Cloud Deploy applies the rendered manifests to it using the target's execution service account.

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: prod-gke
gke:
  cluster: projects/rc-saas-prod-app-01/locations/us-central1/clusters/rc-saas-prod-gke-01
requireApproval: true
executionConfigs:
  - usages: [RENDER, DEPLOY, VERIFY]
    serviceAccount: sa-deploy-prod@rc-saas-shared-cicd-01.iam.gserviceaccount.com
    workerPool: "projects/rc-saas-shared-cicd-01/locations/us-central1/\
workerPools/pool-us-central1-prod"

The workerPool value is quoted because a \-continuation is only a line break inside a double-quoted YAML scalar; in a plain scalar the backslash would be part of the resource name.

A private control plane requires a private worker pool. The workerPool field on the execution config points at a Cloud Build private pool (§23.5) peered into the cluster's network. Without it, deployment to a cluster with no public control-plane endpoint simply cannot connect.

The deploy identity needs Kubernetes RBAC, not just IAM. roles/container.developer on the cluster gets it to the API server; what it may then do is governed by the cluster's RBAC. Bind the deploy identity to a namespace-scoped role rather than cluster-admin, so a compromised deploy account cannot rewrite admission policy.

multiTarget deploys to several clusters as one stage, which is the mechanism for a regional pair or a fleet — one rollout, one approval, several clusters, and a single record of what shipped where.

Pitfall. Cloud Deploy applies manifests; it does not own what is already there. A resource removed from the manifest is not deleted from the cluster unless the tooling prunes, so an obsolete Deployment or a stale NetworkPolicy can survive many releases. Decide the pruning behavior explicitly.

25.6 Cloud Run Deployment §

A Cloud Run target names a location, and each rollout creates a new revision. Traffic movement is a separate, controllable step.

The three flags that make a deploy safe are on gcloud run deploy:

gcloud run deploy billing-prod \
  --image=us-central1-docker.pkg.dev/rc-saas-shared-art-01/prod-docker/\
billing@sha256:DIGEST \
  --region=us-central1 \
  --service-account=sa-run-billing@rc-saas-prod-app-01.iam.gserviceaccount.com \
  --ingress=internal-and-cloud-load-balancing \
  --no-traffic \
  --tag=rc-1-4-2

Deploy with no traffic, verify at the tag URL, then shift. That sequence is what makes a Cloud Run rollout observable, and it is what automaticTrafficControl in a Cloud Deploy canary strategy automates.

--binary-authorization=POLICY applies the deploy-time gate on Cloud Run (§25.10), and --breakglass=JUSTIFICATION is the documented override — which writes the justification into the audit log rather than bypassing the record.

Keep the runtime identity distinct from the deploy identity. --service-account names what the service runs as, which is sa-run-billing; the principal executing the deploy is sa-deploy-prod. Conflating them gives the deploy account the runtime's data access.

Pitfall. --no-traffic still creates a revision that can serve at its tag URL, and that URL is reachable subject to the service's ingress and IAM. A "not yet live" revision under verification is live to anyone who can reach the tagged URL.

25.7 Canary Deployments §

A canary sends a fraction of traffic to the new version, verifies, and increases the fraction. Cloud Deploy models it as a strategy on a stage.

The strategy has two forms:

• canaryDeployment with percentages: [PERCENTAGES] and an optional verify step, which Cloud Deploy expands into phases automatically.
• customCanaryDeployment, where you declare the phases by name with their own percentages and profiles.

Runtime configuration differs by platform. For Cloud Run, runtimeConfig: cloudRun: automaticTrafficControl: true | false decides whether Cloud Deploy manages traffic splits. For GKE, runtimeConfig: kubernetes: selects serviceNetworking: (two Services and a selector switch) or gatewayServiceMesh: (Gateway API-based weighting).

A canary is only a control if verification can fail it. The verify step runs a Skaffold verify task against the canary; if it passes because it only checks that pods are running, the canary is a slower full deployment. Verify something that would actually differ: error rate, a functional probe, an authorization check.

Percentages should start below your noise floor. Ten percent of a service with a 0.1% baseline error rate produces enough traffic to see a regression; ten percent of a service handling forty requests an hour produces nothing. Match the first phase to the traffic volume, not to a habit.

Pitfall. Canary analysis based only on infrastructure metrics misses the failures that matter. A new version that returns HTTP 200 with an authorization bug looks perfect on latency and error rate — which is why §18.13's advice to define "good" from the application applies here too.

25.8 Blue/Green Deployments §

Blue/green runs two complete environments and switches traffic between them atomically. It is an outcome, not a Cloud Deploy strategy.

Cloud Deploy's documented strategies are standard and canary. There is no blue/green strategy in the configuration schema, and a pipeline claiming one is describing something it built out of the platform primitives below.

Two primitives implement it:

gcloud run services update-traffic billing-prod \
  --region=us-central1 \
  --set-tags=green=billing-prod-00042-abc \
  --to-tags=green=100

Blue/green buys instant rollback and costs double capacity. The switch back is another traffic update, measured in seconds rather than in a redeployment — which is why it suits changes where the failure mode is immediate and severe.

Canary is the better default. It surfaces failures on a fraction of traffic rather than all of it, and it costs one environment. Reserve blue/green for changes that cannot be partially deployed: a schema migration with a cutover, a protocol change, a change where mixed versions are incorrect.

Pitfall. Blue/green assumes both versions can coexist against shared state. If the green version has already migrated the database in a way blue cannot read, the instant rollback does not exist and the strategy has given you false confidence.

25.9 Rollbacks §

A rollback returns a target to a previously deployed release. In Cloud Deploy the command lives on the target, not on the rollout.

gcloud deploy targets rollback prod \
  --delivery-pipeline=dp-billing \
  --region=us-central1 \
  --release=billing-1-4-1 \
  --description="Rollback: 1.4.2 authorization regression."

gcloud deploy rollouts rollback does not exist. The rollout group has approve, advance, cancel, ignore-job, retry-job, and describe; rollback is gcloud deploy targets rollback, optionally naming a --release and a --starting-phase-id.

A rollback creates a new rollout of the older release. It is a forward operation in the audit trail, which is correct — the history shows that 1.4.1 was deployed again at a time, by a principal, rather than the record of 1.4.2 disappearing.

Rollback depends on things earlier chapters had to get right: the old artifact still exists in the registry (§24.11), the release is still present, and the change was backward-compatible with whatever state it touched. A cleanup policy that deleted the previous release's image makes rollback impossible at exactly the moment it is needed.

Test the rollback, on a schedule. An untested rollback path is a plan, not a capability, and the usual discovery is that a database migration or a configuration format change made it impossible three releases ago.

Pitfall. Rolling back application code does not roll back data. A release that wrote a new field, changed an encoding, or migrated a schema leaves that state behind, and the older code may not read it. Backward compatibility of the data change is the precondition for rollback, and it is a design decision made when the migration is written.

25.10 Binary Authorization §

Binary Authorization is a deploy-time policy gate: it evaluates the image a workload is about to run against a policy and admits or denies it. §9.27 owns GKE's enforcement configuration and Chapter 37 owns attestation authoring; this section is the gate as a stage of a delivery pipeline.

The policy is a document you import, with a default rule and per-cluster overrides:

gcloud container binauthz policy import policy.yaml --strict-validation

Two enums decide behavior, and they are independent:

Roll out in dry-run first. DRYRUN_AUDIT_LOG_ONLY with REQUIRE_ATTESTATION produces an audit log entry for every deployment that would have been blocked, which is the same rollout discipline as a VPC Service Controls perimeter (§20.8) and for the same reason: the things that break first are all legitimate.

admissionWhitelistPatterns is the exception list and it is where policies quietly die. Every pattern is an image path that bypasses evaluation entirely; a pattern broad enough to cover a whole registry admits anything anyone can push there.

The gate applies beyond GKE. gcloud run deploy --binary-authorization=POLICY applies it to Cloud Run, and --breakglass=JUSTIFICATION is the documented override — which records the justification rather than removing the policy.

Pitfall. A Binary Authorization policy evaluates the image reference presented at admission. If a deployment references a mutable tag, the policy evaluates whatever that tag pointed at during admission, and a later repoint is unevaluated. Digest references (§25.12) and immutable tags (§24.5) are both prerequisites for the gate to mean anything.

25.11 Image Signing §

Signing binds a statement — this image passed this check — to a key, so a later gate can verify it without trusting the pipeline that made the claim.

In Binary Authorization the signed statement is an attestation, created against an attestor. Chapter 37 owns attestor design and the attestation format; the pipeline-side commands are:

gcloud container binauthz create-signature-payload \
  --artifact-url=us-central1-docker.pkg.dev/rc-saas-shared-art-01/prod-docker/\
billing@sha256:DIGEST > payload.json

The payload is then signed with a Cloud KMS key and submitted with gcloud container binauthz attestations create against the attestor.

There is no first-party gcloud artifacts docker images sign command. Signing is either the attestation path above or an external tool such as cosign; this book does not present a Google image-signing command that does not exist.

The signing key belongs in Cloud KMS, in the security project. Following §14.8: a key in rc-saas-shared-sec-01, with roles/cloudkms.signerVerifier granted to the attesting identity on that key alone, and roles/cloudkms.admin held only by the security team.

Who signs is the whole security property. If the build service account can create the attestation that lets its own output deploy, the attestation proves the build ran and nothing more. The attesting identity must be a separate principal that acts on evidence — a scan result, a test result, a human approval.

Pitfall. An attestation is bound to a digest. Re-tagging, re-pushing, or rebuilding produces a different digest and no attestation, which manifests as a deployment that is blocked for reasons nobody can see. The pipeline must carry the digest end to end, from build (§23.10) through promotion (§24.7) to deploy.

25.12 Provenance Verification §

Provenance verification is the deploy-time check that the artifact was built the way you expect. §23.13 generates the provenance; this section consumes it.

Three facts are checkable, and each closes a different hole:

gcloud artifacts docker images describe \
  us-central1-docker.pkg.dev/rc-saas-shared-art-01/prod-docker/billing@sha256:DIGEST \
  --show-provenance --format=json

Verification must happen on the deploy side, not the build side. A build that checks its own provenance proves nothing. The check belongs in a predeploy step of the Cloud Deploy target, or in the attestation decision of §25.11 — somewhere the build identity cannot influence.

Deploy by digest, always. Every manifest, every --images argument, and every Binary Authorization rule references IMAGE@sha256:.... This is the single most repeated instruction in Part IX because it is the assumption every other check depends on.

Cloud Build only generates provenance for artifacts stored in Artifact Registry (§23.13), so an image that came from anywhere else has none to verify — and "no provenance" must fail the gate rather than skip it.

Pitfall. Provenance says how the artifact was built, not whether the source deserved building. It faithfully records a build from a compromised commit on a protected branch. Provenance verification is one input to a decision that also includes review, scanning, and signing.

25.13 Separation of Build and Deploy Identities §

The identity that produces an artifact must not be the identity that deploys it. This is the structural control that makes a compromised build recoverable.

Three principals, three jobs, three permission sets:

Cloud Deploy makes this natural because the execution service account is a per-target field (§25.1). Without Cloud Deploy, the same separation is achievable but requires a deliberate split of pipeline stages across identities, which is why teams that deploy from a single build job almost never have it.

The actAs chain is the enforcement point. Whoever configures a target that runs as sa-deploy-prod needs iam.serviceAccounts.actAs on it (§4.7), so the ability to point a pipeline at a powerful identity is itself a permission.

Log and alert on the exceptions. A principal that acquires both build and deploy roles — even briefly, even for a migration — is a control-plane event worth an alert (§18.15), because it collapses the separation this section exists to create.

Pitfall. Separation is defeated by a shared human. If the same engineer holds roles/clouddeploy.approver and can push to the build repository, the technical separation is real and the process separation is not. Approver groups should exclude the change's author, which is a review-tooling setting rather than an IAM one.

25.14 Production Deployment Controls §

Production deployment controls are the set of conditions a change must satisfy to reach production, expressed so that they cannot be skipped quietly.

Six conditions, and each maps to a mechanism already described:

1. The artifact came from the production repository, written only by the promotion identity (§24.10).
2. It is referenced by digest (§25.12).
3. Binary Authorization admits it (§25.10).
4. A human who did not write it approved (§25.4).
5. The deploy identity is production-specific (§25.13).
6. The rollout is within an allowed window — deploy policies.

Deploy policies are the mechanism for the last one. gcloud deploy deploy-policies manages them and they are applied with gcloud deploy apply like every other Cloud Deploy resource. They constrain when rollouts may occur, which is how a change-freeze window becomes an enforced control instead of an email.

--override-deploy-policies is the break-glass path, present on releases create, rollouts approve, and targets rollback. It records the override in the audit trail, which is exactly what you want: the emergency path exists, it works, and it is visible.

Alert on every override. An override of a deploy policy, a Binary Authorization break-glass, or a skipped pipeline stage is an Admin Activity event (§17.2) and belongs in the §18.15 alert set. The point is not to prevent them — it is that nobody uses one without someone knowing.

Pitfall. Controls that make emergency deployment impossible get removed after the first incident where they cost an hour of downtime. Design the break-glass path deliberately, document it, rehearse it, and instrument it — or the team will build an undocumented one out of console access and nobody will ever see it used.

Chapter Summary §

• Cloud Deploy renders a release once and promotes the same rendered output, so promotion deploys something already reviewed rather than rebuilding per environment.
• A target's executionConfigs names the usages, service account, and worker pool, which is how per-environment deploy identities are configured.
• profiles change configuration per stage; they must never change the image.
• requireApproval defaults to false; set it explicitly on production, and grant roles/clouddeploy.approver to people who did not write the change.
• Deploying to a private GKE control plane requires a Cloud Build private worker pool on the target's execution config.
• Bind the deploy identity to a namespace-scoped Kubernetes role, not cluster-admin.
• On Cloud Run, deploy with --no-traffic and a --tag, verify at the tag URL, then shift traffic — but the tagged revision is already reachable.
• Cloud Deploy's strategies are standard and canary; there is no native blue/green strategy, and blue/green is built from Cloud Run traffic tags or a Kubernetes selector switch.
• A canary is only a control if its verification can fail it, and the first percentage must exceed the service's noise floor.
• Rollback is gcloud deploy targets rollback; gcloud deploy rollouts rollback does not exist.
• Rolling back code does not roll back data, and the previous artifact must still exist in the registry.
• Binary Authorization's evaluationMode and enforcementMode are independent; roll out with DRYRUN_AUDIT_LOG_ONLY first.
• admissionWhitelistPatterns entries bypass evaluation entirely and are where policies quietly die.
• There is no first-party gcloud artifacts docker images sign; signing is the attestation path or an external tool.
• The attesting identity must not be the build identity, or the attestation proves only that the build ran.
• Provenance verification belongs on the deploy side, and "no provenance" must fail the gate rather than skip it.
• Build, promotion, and deploy are three principals with three disjoint permission sets, enforced by the actAs chain.
• --override-deploy-policies and Binary Authorization break-glass are legitimate paths that record themselves; alert on every use.

Security Checklist §

Sources §

• https://cloud.google.com/deploy/docs — Cloud Deploy documentation hub (last validated 2026-09-03)
• https://cloud.google.com/deploy/docs/config-files — delivery pipeline, target, execution config, and canary schema (last validated 2026-09-03)
• https://cloud.google.com/binary-authorization/docs — policy model, evaluation and enforcement modes (last validated 2026-09-03)
• https://cloud.google.com/binary-authorization/docs/using-breakglass — the documented break-glass override (last validated 2026-09-03)
• https://cloud.google.com/run/docs/rollouts-rollbacks-traffic-migration — Cloud Run revisions, tags, and traffic migration (last validated 2026-09-03)