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?
