What actually crosses the project boundary: a token, never a key
A short-lived, signed token — never a static credential — is what lets Cloud Deploy act across a project boundary.
Speaker notes
- Walk the sequence: Cloud Deploy requests a short-lived token as the deployer service account, presents that token to IAM in the target project, IAM checks the binding, and only then does the deploy action actually reach the GKE API.
- The point worth dwelling on: at no point does a long-lived credential cross the project boundary — the service account's identity lives in the tooling project, and what crosses into the target project is a token plus an API call, checked against that project's own IAM policy on every single request.
- This is the same underlying token-exchange pattern Workload Identity Federation uses for external CI systems in the pipeline-security chapter — cross-project deploy and cross-cloud federation are the same mechanism at different scope, worth flagging explicitly as a reusable mental model.
Deck map
01
One pipeline, built deliberately
02
PCDE sections 1-2, and where this course sits in the track
03
ACE operates a resource; PCDE designs the system
04
One tooling project, not one pipeline per environment
05
Dev, staging, and prod should never share one policy
06
What actually crosses the project boundary: a token, never a key
07
A hand-run command leaves no record of why
08
Local Terraform state is a production incident waiting to happen
09
Cloud Foundation Toolkit and Fabric FAST: forked, never left unmodified
10
Terraform for foundations, Config Connector for workload-coupled infra
11
Git decides, automation reconciles — no human runs apply
12
Cloud Build's whole job: source in, tested artifact out
13
Built-in substitutions are automatic; user-defined ones need an underscore
14
An unfiltered branch trigger is a budget incident waiting to happen
15
Three repository modes, and scanning stops at the virtual layer
16
Cheap checks first, expensive checks last
17
Cloud Build produces; Cloud Deploy promotes — never the reverse
18
Four objects: DeliveryPipeline, Target, Release, Rollout
19
Canary limits exposure; blue/green makes the cutover atomic
20
A human gates production; automation gates everything else
21
Meridian's full path: merge to production, one continuous record
22
Credentials go in Secret Manager; configuration goes in Parameter Manager
23
An ENV baked into a Dockerfile is still build-time injection
24
One question resolves almost every config-placement decision
25
Ephemeral environments need a TTL, or they're not actually ephemeral
26
Rapid, Regular, Stable — and a maintenance exclusion set too late doesn't help
27
A compromised pipeline is every environment it deploys to
28
SLSA grades the pipeline's trustworthiness, not any single artifact
29
Default-deny, or an unlisted cluster accepts anything
30
Only /home survives a session — everything else is rebuilt fresh
31
Every chapter of this course, in one sequence
32
Readiness checklist