Skip to content

Guardrails / terraform

Terraform modules are pinned ​

terraform/modules-pinned@v1

Every module a Terraform root pulls from a registry or a git URL names a version, so the same commit always resolves to the same module code.

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

Collectors ​

This guardrail doesn't gather anything itself. It relies on the collectors below, which the CLI runs once per build before any check, and reads what they found from GUARDRAIL_FACTS. If a collector collects nothing, this guardrail is skipped, not failed.

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. Everything is read from the files themselves, so it works on a runner with no Terraform installed. When the terraform CLI is there, the versions an initialised root has already resolved are added.none

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

Configuration ​

json
{
  "guardrails": {
      "failOn": "error",
      "checks": [
          {
              "use": "terraform/modules-pinned@v1",
              "severity": "error",
              "with": {
                  "allowMovableRefs": "false"
              },
              "exemptions": []
          }
      ]
  }
}

Inputs ​

InputDescriptionDefaultEnvironment variable
allowMovableRefsWhether a git source pinned to a tag or branch instead of a commit SHA counts as pinned. false requires a 40 character SHA, the only ref nobody can move.falseGUARDRAIL_INPUT_ALLOWMOVABLEREFS

How to fix ​

Pin the modules named in the violations. For a registry source, pin with version:

hcl
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.8.1"
}

For a git source, pin with a ref in the URL. A tag isn't enough, because a tag can move:

hcl
module "vpc" {
  source = "git::https://github.com/company/terraform-vpc.git?ref=6f3a1c2d9b8e4f7a0c5d2e1b3a4f5c6d7e8f9a0b"
}

With an unpinned module, the plan you reviewed and the plan that was applied can come from different code. A module in this repository, referenced with a relative source, is already pinned by the commit and isn't checked.

More in terraform ​

  • terraform/no-plaintext-secrets. Every Terraform variable named like a credential declares sensitive = true.
  • terraform/providers-pinned. Every provider a live Terraform root requires is pinned to one exact version, and the lock file that resolves them is committed.
  • 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 an encrypted backend, so its state isn't stored in the clear in its bucket.
  • 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