All skills
hashicorp avatar

/terraform-style-guide

@4451cec official
by hashicorphashicorp/agent-skills880 stars
130

Generate Terraform HCL code following HashiCorp's official style conventions and best practices. Use when writing, reviewing, or generating Terraform configurations.

Use this Skill: https://skilld.dev/gh/hashicorp/agent-skills/terraform-style-guide

This session only. Nothing lands on disk.

SECURITY.md

≈1.2k tokens on demand. Your agent reads this file only when SKILL.md points to it.

Terraform Style Guide - Security

When generating code, apply security hardening:

  • Enable encryption at rest by default
  • Configure private networking where applicable
  • Apply principle of least privilege for security groups
  • Enable logging and monitoring
  • Never hardcode credentials or secrets
  • Mark sensitive outputs with sensitive = true
  • Use ephemeral resources and write-only attributes for sensitive data when possible

Example: Secure S3 Bucket

resource "aws_s3_bucket" "data" {
  bucket = "${var.project}-${var.environment}-data"
  tags   = local.common_tags
}

resource "aws_s3_bucket_versioning" "data" {
  bucket = aws_s3_bucket.data.id

  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "data" {
  bucket = aws_s3_bucket.data.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.s3.arn
    }
  }
}

resource "aws_s3_bucket_public_access_block" "data" {
  bucket = aws_s3_bucket.data.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Ephemeral resources

Ephemeral resources prevent sensitive data being stored in state. For more information on ephemeral resources, see the Terraform documentation.

Before you generate code for an ephemeral resource, check that the Terraform version is greater than or equal to 1.11.0.

Then, follow this priority order for managing sensitive attributes:

  1. First priority: Native secrets manager integration If a resource has the ability to automatically manage a sensitive attribute by storing it in a secrets manager (e.g., AWS Secrets Manager, Azure Key Vault), use that configuration. This is the preferred approach.

    # Bad
    resource "aws_rds_cluster" "example" {
      cluster_identifier = "example"
      database_name      = "test"
      master_username    = "test"
      master_password    = var.db_master_password
    }
    
    # Good, managed by AWS Secrets Manager by default
    resource "aws_rds_cluster" "test" {
      cluster_identifier          = "example"
      database_name               = "test"
      manage_master_user_password = true
      master_username             = "test"
    }
  2. Second priority: Write-only attributes with ephemeral resources If a resource has a write-only attribute but no native secrets manager integration, use an ephemeral resource for the sensitive data and pass that to the write-only attribute. Default the write-only version to 1.

    # Bad
    resource "random_password" "password" {
      length           = 16
      special          = true
      override_special = "!#$%&*()-_=+[]{}<>:?"
    }
    
    resource "vault_kv_secret_v2" "example" {
      mount               = vault_mount.kvv2.path
      name                = "secret"
    
      data_json = jsonencode(
        {
          password = "${random_password.password.result}",
        }
      )
    }
    
    # Good
    ephemeral "random_password" "password" {
      length           = 16
      special          = true
      override_special = "!#$%&*()-_=+[]{}<>:?"
    }
    
    resource "vault_kv_secret_v2" "example" {
      mount               = vault_mount.kvv2.path
      name                = "secret"
    
      data_json_wo = jsonencode(
        {
          password = "${ephemeral.random_password.password.result}",
        }
      )
      data_json_wo_version = 1
    }

    If you need to retrieve a secret from a secrets manager to pass to a resource, use the ephemeral version of the resource to retrieve the secret and pass it to another resource.

    # Good
    ephemeral "vault_kv_secret_v2" "db_secret" {
      mount = vault_mount.kvv2.path
      mount_id = vault_mount.kvv2.id
      name = vault_kv_secret_v2.db_root.name
    }
    
    resource "vault_database_secret_backend_connection" "postgres" {
      backend       = vault_mount.db.path
      name          = "postrgres-db"
      allowed_roles = ["*"]
    
      postgresql {
        connection_url = "postgresql://{{username}}:{{password}}@localhost:5432/postgres"
        password_authentication = ""
        username = "postgres"
        password_wo = tostring(ephemeral.vault_kv_secret_v2.db_secret.data.password)
        password_wo_version = 1
      }
    }
  3. Last resort: Regular resources Only use a regular resource that has sensitive data written to state if neither of the above options are available, resource does not offer a write-only attribute or ephemeral resource alternative, or the Terraform version is less than 1.11.0.

Source: SKILL.md on GitHub

No alerts16d5 checks · Risk SAFE
  • Gen Agent Trust Hub16d

    This skill provides guidance for generating Terraform HCL code following official HashiCorp style and security conventions. It encourages best practices like version pinning, sensitive value marking, and the use of ephemeral resources to protect secrets. No security risks were identified.

  • Socket16d

    No alerts

  • Snyk16d

    Risk: LOW · No issues

  • Runlayer7mo

    1/1 file flagged

  • ZeroLeaks5mo

    Score: 93/100 · 2 sections analyzed

Signed by skilld at 4451cec. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub 3 days ago.

Activeupdated 2 months ago
metadata
{
  "lifecycle-status": "active"
}
  • terraform
  • hcl
  • hashicorp
  • infrastructure-as-code
  • aws
  • code-generation
  • style-guide
  • validation

README badge

README badge for hashicorp/agent-skills/terraform-style-guide

Enforces HashiCorp's official Terraform style conventions when generating or reviewing HCL code, including file organization, naming conventions, formatting rules, and security practices. Use this skill when writing Terraform configurations to ensure consistent structure, proper variable/output documentation, and compliance with HashiCorp standards.

Generated from the current SKILL.md.

Does this skill enforce HashiCorp's official style guide?
Yes. The skill generates and maintains Terraform code following HashiCorp's official style conventions, including indentation, naming, block organization, and file structure standards.
What file structure should I use?
The skill prescribes organizing Terraform into terraform.tf (version requirements), providers.tf (provider config), main.tf (resources), variables.tf (inputs), outputs.tf (outputs), and locals.tf (local values).
Should I use count or for_each for dynamic resources?
The skill recommends for_each for multiple named resources and count only for conditional creation (e.g., enabling a resource based on a boolean variable).
What validation tools does this skill recommend?
Run terraform fmt -recursive and terraform validate before committing. The skill also lists tflint for linting, and checkov or tfsec for security scanning.
Does this skill cover sensitive data handling?
Yes. Mark sensitive values with sensitive = true in variables and outputs, never commit .tfvars files with secrets, and refer to the SECURITY.md guidance for encryption and state protection practices.

Generated from the current SKILL.md. These answers refresh after source changes.