Terratags v0.6.0: Remote Configuration and Google Cloud Support

Terratags continues to evolve, and v0.6.0 brings two significant features: remote configuration support and Google Cloud Provider support. These additions make Terratags extend its reach beyond AWS and Azure to cover the major cloud providers.

What's New in v0.6.0

Remote Configuration Support

One of the requested features was the ability to centralize configuration management. This allows team to avoid duplicating tag requirements across multiple repositories and maintain consistency across their infrastructure.

v0.6.0 introduces remote configuration support, allowing you to load your Terratags configuration from:

HTTP/HTTPS URLs

terratags -config https://example.com/configs/terratags.yaml -dir ./infra

Git Repositories

# HTTPS with branch/tag specification
terratags -config https://github.com/org/configs.git//terratags.yaml?ref=main -dir ./infra

# SSH support for private repositories
terratags -config [email protected]:org/configs.git//path/to/config.yaml?ref=v1.0.0 -dir ./infra

This is particularly powerful for organizations that want to:

• Version their tagging policies alongside their infrastructure code
• Use different configurations for different environments (dev, staging, prod)
• Maintain audit trails of configuration changes
• Leverage Git's branching and tagging for configuration management

Version Pinning and Environment-Specific Configs

The Git integration supports referencing specific branches, tags, or commits:

# Production uses stable tagged version
terratags -config https://github.com/org/configs.git//prod-config.yaml?ref=v2.1.0

# Development uses latest from main branch
terratags -config https://github.com/org/configs.git//dev-config.yaml?ref=main

# Specific commit for reproducible builds
terratags -config https://github.com/org/configs.git//config.yaml?ref=abc123def

Google Cloud Provider Support

The second major addition is full support for Google Cloud Platform. GCP uses 'labels' instead of 'tags' for resource metadata.

Basic GCP Label Validation

resource "google_compute_instance" "web_server" {
  name         = "web-server-01"
  machine_type = "e2-medium"
  zone         = "us-central1-a"

  labels = {
    environment = "production"
    project     = "web-app"
    owner       = "[email protected]"
    name        = "web-server-01"
  }
}

Google Provider default_labels Support

Just like AWS and Azapi provider's default_tags , Google provider's default_labels are fully supported:

provider "google" {
  project = "my-project-id"
  region  = "us-central1"

  default_labels = {
    environment = "production"
    owner       = "team-platform"
    managed_by  = "terraform"
  }
}

resource "google_storage_bucket" "data_bucket" {
  name     = "company-data-bucket"
  location = "US"

  # Only need to specify labels not covered by default_labels
  labels = {
    name    = "data-bucket"
    project = "analytics"
  }
}

In this example, the bucket will have all required labels: name and project from the resource-level labels, and environment, owner, and managed_by from the provider's default_labels.

Multi-Cloud Tagging Consistency

With v0.6.0, Terratags now supports all three major cloud providers with their respective tagging mechanisms:

• AWS: tags with default_tags support
• Azure: tags with azapi default_tags support
• Google Cloud: labels with default_labels support

This means you can maintain consistent tagging policies across your entire multi-cloud infrastructure using a single tool and configuration format.

Validation in CI/CD

# GitHub Actions example
- name: Validate AWS Resources
  run: terratags -config https://example.com/aws-tags.yaml -dir ./aws-infra

- name: Validate GCP Resources  
  run: terratags -config https://example.com/gcp-labels.yaml -dir ./gcp-infra

- name: Validate Azure Resources
  run: terratags -config https://example.com/azure-tags.yaml -dir ./azure-infra

Pattern Validation

The advanced pattern validation introduced in earlier versions works consistently across all providers:

# Works for AWS tags, Azure tags, and GCP labels
required_tags:
  environment:
    pattern: "^(dev|test|staging|prod)$"

  owner:
    pattern: "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$"

  cost_center:
    pattern: "^CC-[0-9]{4}$"

Getting Started with v0.6.0

Installation

# Using Homebrew (recommended)
brew install terratags/tap/terratags

# Or download from GitHub releases
# https://github.com/terratags/terratags/releases/tag/v0.6.0

Quick Start with Remote Config

1. Set up a remote configuration:

# https://example.com/terratags.yaml
required_tags:
  environment:
    pattern: "^(dev|test|staging|prod)$"
  owner:
    pattern: "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$"
  project: {}
  name: {}

1. Run validation:

terratags -config https://example.com/terratags.yaml -dir ./infra -report report.html

1. Set up pre-commit hooks:

repos:
  - repo: https://github.com/terratags/terratags
    rev: v0.6.0
    hooks:
      - id: terratags
        args: [--config=https://example.com/terratags.yaml]

Looking Ahead

There are a few items in the report generation which I want to look to implement, without breaking existing structure and including all the metadata.

Resources

• GitHub Repository: https://github.com/terratags/terratags
• Documentation: https://terratags.github.io/terratags/
• Remote Config Examples: https://terratags.github.io/terratags/examples/remote_config/
• Release Notes: https://github.com/terratags/terratags/releases/tag/v0.6.0

If you're using Terratags and have been waiting for centralized configuration management, v0.6.0 is definitely worth the upgrade. As always, I'd love to hear about your experience and any feedback you have!