Terraform CI/CD with Google Cloud: Plan on Pull Request and Apply with Approval

Simple Terraform codes on laptop is alright for learning. But, at some point, things gotten more complex and infrastructure changes need a more controlled workflow.

For my second Terraform x Google Cloud portfolio artifact, I had already built a production like web platform with:

VPC
app and DB subnets
Cloud NAT
private backend VMs
regional Managed Instance Group
HTTP/HTTPS Load Balancer
Cloud Armor security policy
remote Terraform state
modular Terraform structure

In this version, I added the next operational layer:

Terraform CI/CD

The goal was simple:

Pull Request -> Terraform Plan
Manual Approval -> Terraform Apply
No service account JSON key

This became:

v2.0 — Terraform CI/CD with GitHub Actions and Workload Identity Federation

Checkout my github! terraform-gcp-production-lite-web-platform

Why I Built This

Before this version, the workflow was still done locally:

local terminal
  -> terraform fmt
  -> terraform validate
  -> terraform plan
  -> terraform apply

That works for my learning, But i understand that in a team setting this way of doing things locally is not sustainable.

Thus, making me questions:

Can the change be reviewed before apply?
Can the Terraform plan run automatically on pull request?
Can apply require approval?
Can GitHub Actions authenticate to Google Cloud without a static key?
Can the workflow use remote state safely?

v2.0 was built to answer those questions.

What v2.0 Adds

This release adds:

GitHub Actions
Terraform plan on pull request
Terraform apply through manual workflow
GitHub environment approval before apply
Workload Identity Federation
Google service account impersonation
No service account JSON key
Remote state access from CI/CD
GitHub CLI-based release workflow

The important part is not just automation.

The important part is change control.

Final CI/CD Flow

The new workflow looks like this:

Pull Request
  -> terraform fmt -check
  -> terraform init
  -> terraform validate
  -> terraform plan
  -> upload plan artifact
  -> comment plan summary on PR

Manual Apply
  -> workflow_dispatch
  -> confirm input: APPLY
  -> GitHub environment approval
  -> terraform plan -out=tfplan
  -> terraform apply tfplan

This separates review from execution.

The PR workflow answers:

What will Terraform change?

The apply workflow answers:

Are we approved to apply this change?

Authentication Design

The most important security decision in this version:

No service account JSON key.

Instead of storing a long-lived Google Cloud key in GitHub Secrets, the workflow uses Workload Identity Federation.

The authentication flow is:

GitHub Actions OIDC token
  -> Google Workload Identity Provider
  -> Terraform CI/CD service account impersonation
  -> Google Cloud APIs

The GitHub repository is restricted through the Workload Identity Provider attribute condition:

assertion.repository == "abrahamparn/terraform-gcp-production-lite-web-platform"

That means the provider is only intended to trust this specific repository.

Why Workload Identity Federation Matters

A service account JSON key is a long-lived credential.

If it leaks, the impact can be serious.

Workload Identity Federation avoids that by allowing GitHub Actions to exchange its OIDC identity for short-lived Google Cloud access.

For this project, GitHub Actions impersonates a dedicated service account:

terraform-cicd@PROJECT_ID.iam.gserviceaccount.com

This gives the CI/CD pipeline a clear operational identity.

Workflow 1 — Terraform Plan on Pull Request

The first workflow runs on pull requests to main.

File:

.github/workflows/terraform-plan.yml

The workflow performs:

checkout repository
set up Terraform
authenticate to Google Cloud using WIF
set up gcloud
terraform fmt -check -recursive
terraform init
terraform validate
terraform plan
generate plain-text plan
upload plan artifact
comment plan summary on PR

In the screenshot, the Terraform Plan workflow successfully completed all steps:

Checkout repository
Set up Terraform
Authenticate to Google Cloud
Set up gcloud
Terraform format check
Terraform init
Terraform validate
Terraform plan
Generate plain-text plan
Upload Terraform plan artifact
Comment plan summary on PR

This is the main review workflow.

It allows infrastructure changes to be reviewed before they are applied.

Workflow 2 — Terraform Apply with Manual Approval

The second workflow is manually triggered.

File:

.github/workflows/terraform-apply.yml

The workflow uses:

workflow_dispatch
confirm_apply input
GitHub environment: terraform-apply
manual approval
terraform plan before apply
terraform apply using saved plan file

The apply workflow has two jobs:

Terraform Plan Before Apply
Terraform Apply

In the screenshot, the apply workflow succeeded after environment approval.

The deployment protection section shows:

Environment: terraform-apply
Approval: approved
Comment: go on

That approval gate is the main safety control before applying infrastructure changes.

Why I Still Run Plan Before Apply

One question I had while building this was:

Should the apply workflow reuse the PR plan artifact?

For this version, I decided not to.

Instead, the apply workflow creates a fresh plan immediately before apply.

Why?

Because PR plan artifacts can become stale.

Between PR review and manual apply:

state may change
main branch may change
plan artifact may expire
another workflow may run

So the safer v2.0 pattern is:

PR plan = review signal
Apply workflow plan = final execution plan

Then the apply step uses:

terraform apply tfplan

This keeps apply tied to the plan generated inside the apply workflow.

GitHub Environment Approval

The apply workflow uses this environment:

terraform-apply

This allows GitHub deployment protection rules to act as the approval gate.

The result is:

No automatic apply from pull request.
No apply just because code was pushed.
Apply only happens after manual workflow trigger and approval.

Repository Variables

I used GitHub repository variables for non-secret configuration:

GCP_PROJECT_ID
GCP_PROJECT_NUMBER
GCP_REGION
GCP_WORKLOAD_IDENTITY_PROVIDER
GCP_SERVICE_ACCOUNT
TF_WORKING_DIR
TF_VERSION

These values are not service account keys.

No Google Cloud JSON key is stored in GitHub.

Environment tfvars Strategy

One practical issue with Terraform CI/CD is variable management.

My project uses a lot of variables such as:

subnets
firewall_rules
service_accounts
Cloud Armor rules
managed SSL certificate domains

Passing all of that through TF_VAR_* environment variables would become messy.

So for this portfolio project, I used:

environments/dev.tfvars

This file contains non-sensitive environment configuration.

The workflow runs:

terraform plan -var-file=environments/dev.tfvars

and:

terraform plan -var-file=environments/dev.tfvars -out=tfplan

Important rule:

Only non-sensitive values should be committed.

Secrets should not be placed in dev.tfvars.

GitHub CLI Operations

I also tried to minimize GitHub UI usage.

For example, releases can be created using:

gh release create v2.0.0 \
  --title "v2.0.0 — Terraform CI/CD with GitHub Actions and WIF" \
  --notes "This release adds Terraform plan on pull request, manual approval before apply, and no key Google Cloud authentication through WIF."

The pull request can also be created using CLI:

gh pr create \
  --base main \
  --head feature/v2.0-terraform-cicd-wif \
  --title "add Terraform CI/CD with GitHub Actions and WIF" \
  --body "This PR introduces Terraform CI/CD with GitHub Actions, plan on pull request, manual approval before apply, and Workload Identity Federation with no SA JSON key."

And the manual apply workflow can be triggered with:

gh workflow run "Terraform Apply" \
  -f confirm_apply=APPLY \
  -f git_ref=main

The only part where UI is still useful is the environment approval step, because that is the point of having a manual deployment gate.

Evidence From the Workflow Runs

For this version, I captured two main screenshots.

Terraform Plan Workflow

The Terraform Plan workflow succeeded on pull request.

It completed:

authentication to Google Cloud
terraform fmt check
terraform init
terraform validate
terraform plan
plan artifact upload
PR plan comment

This proves the review workflow works.

Terraform Apply Workflow

The Terraform Apply workflow also succeeded.

It was manually triggered from main, required environment approval, then executed:

Terraform Plan Before Apply
Terraform Apply

The deployment protection section shows that the terraform-apply environment was approved before apply continued.

This proves the execution workflow works.

One Warning I Noticed

The workflow showed a warning related to Node.js 20 actions being deprecated.

This did not break the workflow.

The run still succeeded.

What This Version Does Not Solve Yet

v2.0 is intentionally focused.

It does not yet include:

policy-as-code
cost estimation
drift detection automation
custom least-privilege Terraform IAM role
multi-environment promotion
automatic rollback
scheduled plan

Those are future improvements.

For this version, the objective was:

reviewable plan
manual approved apply
keyless authentication

Final Architecture After v2.0

The infrastructure platform now has two layers:

Runtime platform

HTTPS Load Balancer
Cloud Armor
Backend Service
Regional MIG
Private backend VMs
Cloud NAT

Delivery platform

GitHub Pull Request
Terraform Plan workflow
GitHub Environment Approval
Terraform Apply workflow
Workload Identity Federation
No service account JSON key

That is the main improvement.

The project moved from:

I can provision infrastructure.

to:

I can manage infrastructure changes through a controlled delivery workflow.

Version Timeline

v1.0 — Production-Lite HTTP Platform
v1.1 — HTTPS and Custom Domain
v1.2 — Security Hardening with Cloud Armor
v2.0 — Terraform CI/CD with GitHub Actions and WIF

Next, I may continue with:

v2.1 — Drift Detection and Recovery

Because after CI/CD, the next important Terraform question is:

What happens when someone changes infrastructure outside Terraform?

推荐订阅源

DEV Community