Google Cicd Terraform

Terraform GCP Skill

This skill provides expert-level guidance for architecting, deploying, and managing GCP infrastructure using Terraform.

🎯 When to Use This Skill

• Designing GCP Landing Zones (Projects, Folders, Shared VPCs).
• Provisioning Google Cloud resources (GKE, Cloud Run, Cloud SQL, Spanner).
• Setting up remote state management via GCS Backend.
• Implementing IAM least-privilege via Terraform.
• Troubleshooting terraform plan discrepancies in GCP.

🏗️ Core Architecture: GCS Backend & State

Always use a GCS backend for state. Local state is strictly for local prototyping and must never be committed. If local state direcotry is used, add it to .gitignore.

Standard Backend Configuration

terraform {
  backend "gcs" {
    bucket  = "tf-state-${var.project_id}"
    prefix  = "terraform/state/${var.environment}"
  }
}

Note: The GCS bucket must have Object Versioning enabled to allow recovery from accidental state corruption or overlapping writes.

Required Provider Version

Use the Google Cloud Terraform provider version 7.20.0 or higher. This skill utilizes features (e.g., Developer Connect) introduced in Google Provider v7.20.0.

terraform {
  required_version = ">= 1.6.0"

  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 7.20.0" 
    }
  }
}

To retrieve the latest version of the Google provider, use the following command:

curl -s https://registry.terraform.io/v1/providers/hashicorp/google | jq -r .version

🛠️ Execution Protocol (Safety First)

The Agent must follow this lifecycle for every infrastructure change to ensure idempotency and prevent production outages:

1. Initialize (terraform init):

   • Verify backend connectivity.

   • Ensure provider plugins are downloaded and versions are locked in .terraform.lock.hcl.

2. Validate (terraform validate & tflint):

   • Check for internal HCL consistency.

   • Run tflint with the Google plugin to catch cloud-specific deprecated fields or non-optimal configurations.

3. Plan (terraform plan -out=tfplan):

   • Generate a speculative execution plan.

   • Mandatory Step: The Agent must summarize the plan for the user, specifically highlighting any Destroy actions.

4. Apply (terraform apply tfplan):

   • Strict Constraint: Only execute the application after the user provides explicit manual confirmation.

🔍 Live Provider Documentation Lookup

To prevent hallucinations regarding new fields or deprecated attributes, the Agent must verify the grounded truth of the provider schema.

Schema Inspection via CLI The primary command for retrieving the machine-readable schema of the currently initialized providers is:

$ terraform providers schema -json

🛡️ GCP-Specific Standards

1. Resource Naming & "Main" Pattern To maintain a clean module interface, use the main identifier for singleton resources (the primary resource the module is named after). Use underscores for identifiers and hyphens for names.

   resource "google_compute_network" "main" {
     name                    = "${var.prefix}-vpc"
     auto_create_subnetworks = false
   }
   

2. IAM Management

   • Never use google_project_iam_policy: This resource is authoritative and replaces the entire IAM policy for the project. It is the #1 cause of accidental lockouts.

   • Avoid google_project_iam_policy: This resource is authoritative for the entire project and is a common cause of accidental lockouts.

   • Prefer google_project_iam_member or google_project_iam_binding:

     • google_project_iam_member is additive and safely grants a role to a single member.
     • google_project_iam_binding is authoritative for a single role. It's useful for managing all members of a role, but be aware it overwrites existing members for that role.

   • Shared VPC: Always distinguish between Host projects (where the network lives) and Service projects (where resources consume the network).

   • Private Google Access: Subnets should always have private_ip_google_access = true.

   • Workload Identity: Prefer GKE Workload Identity over static Service Account JSON keys.

3. Cloud Build Triggers with Developer Connect When using Developer Connect git repository links, use developer_connect_event_config — NOT repository_event_config. The repository_event_config block is for Cloud Build v2 repository connections and will not work with Developer Connect resources. An example block to create a Cloud Build trigger with Developer Connect git repository link is as follows:

   resource "google_cloudbuild_trigger" "main" {
     developer_connect_event_config {
       git_repository_link = google_developer_connect_git_repository_link.main.id
       push {
         branch = var.trigger_branch
       }
     }
   }
   

4. Developer Connect Connection When configuring google_developer_connect_connection, always set github_app to "DEVELOPER_CONNECT". Using "FIREBASE" is incorrect and will cause triggers to fail.

   resource "google_developer_connect_connection" "main" {
     location      = var.region
     connection_id = var.connection_id
     project       = var.project_id
   
     github_config {
       github_app = "DEVELOPER_CONNECT" # CORRECT
       authorizer_credential {
         oauth_token_secret_version = "" # Populated after manual authorization
       }
     }
   
     depends_on = [google_project_service.main["developerconnect.googleapis.com"]]
   
     lifecycle {
       ignore_changes = [github_config[0].authorizer_credential]
     }
   }
   

5. Developer Connect Git Repository Link When configuring google_developer_connect_git_repository_link, use parent_connection and git_repository_link_id as required arguments.

   resource "google_developer_connect_git_repository_link" "main" {
     location                = var.region
     parent_connection       = google_developer_connect_connection.main.connection_id
     git_repository_link_id  = "my-repo-link"
     clone_uri               = var.github_repo_uri
   }
   

📂 Directory Structure

Follow this standard to ensure compatibility with Antigravity (AGY) discovery and Google best practices:

.
└── terraform/
    ├── main.tf              # Entry point / Resource definitions
    ├── variables.tf         # Typed variables with units and descriptions
    ├── outputs.tf           # Resource ID outputs (no direct input pass-through)
    ├── versions.tf          # Provider version pinning
    ├── network.tf           # (Optional) Grouped networking resources
    ├── examples/            # Example usage for modules
    ├── files/               # Static files (startup scripts, etc.)
    ├── templates/           # .tftpl templates
    ├── scripts/             # Scripts called by Terraform
    └── helpers/             # Scripts NOT called by Terraform

⚠️ Anti-Patterns (Do NOT do these)

• ❌ Legacy GitHub Triggers: Do not use the legacy github block in google_cloudbuild_trigger. Always use developer_connect_event_config.

• ❌ Hardcoded IDs: Never hardcode Project IDs. Use variables or data "google_project" sources.

• ❌ Service Account Keys: Never generate or store .json keys. Use Workload Identity Federation or the default metadata server.

• ❌ Hardcoded IDs: Never hardcode Project IDs. Use variables or a data "google_project" source.

• ❌ Broad Scopes: Avoid cloud-platform scopes for GKE nodes; use fine-grained IAM roles instead.

• ❌ Uppercase Types: Terraform variable types must be lowercase (e.g., type = string not type = STRING).

🧪 Testing Strategy

• Static Analysis: Use checkov, trivy, or terrascan to catch insecure GCP configurations (e.g., public GCS buckets).

• Integration Testing: Use terraform test (v1.6+) to assert that GCP labels and network tags are correctly applied to resources before full deployment.