Skip to content
BETAGuardrails are in beta. The library, the configuration format and the CLI command can still change.

Guardrails / terraform

Terraform providers are pinned

terraform/providers-pinned@v1

Every provider a live Terraform root requires is pinned to one exact version, and the lock file that resolves them is committed.

Idterraform/providers-pinned
Versionv1
Categoryterraform
Default severityerror
Interpreterpython3
Timeout30 seconds
Violations tolerated0
Collectsterraform

Collectors

This guardrail gathers nothing itself. It depends on the collectors below, which the CLI runs once per build before any check, and reads what they found out of GUARDRAIL_FACTS. A collector that collects nothing skips this guardrail rather than failing it.

CollectorGathersInputs it is given
terraformThe Terraform configuration in the checkout: every root directory holding .tf files, the backend it stores state in, the providers and modules it takes on and how tightly they are pinned, the resources it declares, the variables it takes, the lock file that resolves it, and any state file left in the tree. Read out of the files themselves, so it works on a runner with no Terraform installed, and enriched with the versions an initialised root has already resolved when the terraform CLI is there.none

The inputs above are this guardrail's own, passed straight through. Configuring one in buildnote.json changes what is collected, and two guardrails configured the same way share the one collection.

Configuration

json
{
  "guardrails": {
      "failOn": "error",
      "comment": true,
      "checks": [
          {
              "use": "terraform/providers-pinned@v1",
              "severity": "error",
              "with": {
                  "requireLockfile": "true",
                  "modulePaths": "modules/*,*/modules/*"
              },
              "exemptions": []
          }
      ]
  }
}

Inputs

InputDescriptionDefaultEnvironment variable
requireLockfileWhether a root that requires providers must commit a .terraform.lock.hcl. A root that requires none is never asked for one.trueGUARDRAIL_INPUT_REQUIRELOCKFILE
modulePathsComma separated globs naming directories that hold reusable modules rather than live roots. A module declares no backend and pins nothing, so it is not judged here. A directory another root takes on with a local source is recognised as a module whether or not it matches.modules/*,*/modules/*GUARDRAIL_INPUT_MODULEPATHS

How to fix

Pin each provider to the exact version, and commit the lock file terraform init writes:

hcl
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "6.4.0"
    }
  }
}
bash
terraform init
git add .terraform.lock.hcl

~> 6.0 lets a runner resolve a version nobody reviewed, so the apply can run against a provider the approved plan never saw. The lock file records the checksums as well as the versions, which is what makes a swapped provider visible rather than merely a new one.

A reusable module is the exception and declares a range instead: the root that calls it is what pins. Name your module directories in modulePaths and they are left alone.

More in terraform

  • terraform/modules-pinned. Every module a Terraform root takes from a registry or a git URL names the version it takes, so the same commit resolves to the same module twice.
  • terraform/no-plaintext-secrets. Every Terraform variable named like a credential declares sensitive = true.
  • terraform/remote-state. Every live Terraform root stores its state in a remote backend, and no state file is left in the checkout.
  • terraform/state-encrypted. Every live Terraform root declares its backend encrypted, so the state it writes is not readable from the bucket it sits in.
  • terraform/state-locking. Every live Terraform root declares state locking, so two applies cannot write the same state at once.

All 6 terraform guardrails

Buildnote Limited
Registered in England and Wales, Reg: 16140412