DEV Community

Abraham Naiborhu
Abraham Naiborhu

Posted on

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

#googlecloud #terraform #devops #cloud

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
Enter fullscreen mode Exit fullscreen mode

In this version, I added the next operational layer:

Terraform CI/CD
Enter fullscreen mode Exit fullscreen mode

The goal was simple:

Pull Request -> Terraform Plan
Manual Approval -> Terraform Apply
No service account JSON key
Enter fullscreen mode Exit fullscreen mode

This became:

v2.0 — Terraform CI/CD with GitHub Actions and Workload Identity Federation
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

This separates review from execution.

The PR workflow answers:

What will Terraform change?
Enter fullscreen mode Exit fullscreen mode

The apply workflow answers:

Are we approved to apply this change?
Enter fullscreen mode Exit fullscreen mode

Authentication Design

The most important security decision in this version:

No service account JSON key.
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

assertion.repository == "abrahamparn/terraform-gcp-production-lite-web-platform"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The workflow uses:

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

The apply workflow has two jobs:

Terraform Plan Before Apply
Terraform Apply
Enter fullscreen mode Exit fullscreen mode

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

The deployment protection section shows:

Environment: terraform-apply
Approval: approved
Comment: go on
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

So the safer v2.0 pattern is:

PR plan = review signal
Apply workflow plan = final execution plan
Enter fullscreen mode Exit fullscreen mode

Then the apply step uses:

terraform apply tfplan
Enter fullscreen mode Exit fullscreen mode

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

GitHub Environment Approval

The apply workflow uses this environment:

terraform-apply
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

So for this portfolio project, I used:

environments/dev.tfvars
Enter fullscreen mode Exit fullscreen mode

This file contains non-sensitive environment configuration.

The workflow runs:

terraform plan -var-file=environments/dev.tfvars
Enter fullscreen mode Exit fullscreen mode

and:

terraform plan -var-file=environments/dev.tfvars -out=tfplan
Enter fullscreen mode Exit fullscreen mode

Important rule:

Only non-sensitive values should be committed.
Enter fullscreen mode Exit fullscreen mode

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."
Enter fullscreen mode Exit fullscreen mode

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."
Enter fullscreen mode Exit fullscreen mode

And the manual apply workflow can be triggered with:

gh workflow run "Terraform Apply" \
  -f confirm_apply=APPLY \
  -f git_ref=main
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Those are future improvements.

For this version, the objective was:

reviewable plan
manual approved apply
keyless authentication
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Delivery platform 

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

That is the main improvement.

The project moved from:

I can provision infrastructure.
Enter fullscreen mode Exit fullscreen mode

to:

I can manage infrastructure changes through a controlled delivery workflow.
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Next, I may continue with:

v2.1 — Drift Detection and Recovery
Enter fullscreen mode Exit fullscreen mode

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

What happens when someone changes infrastructure outside Terraform?
Enter fullscreen mode Exit fullscreen mode

Top comments (0)