DevSecOps Practice Hub

Terraform Security

Secure Terraform state, providers, modules and plan/apply workflows.

IntermediateTerraform SecurityInfrastructureCloud

Where it fits in the lifecycle

  1. Plan
  2. Code
  3. Build
  4. Test
  5. Release
  6. Deploy
  7. Operate
  8. Monitor
  • Code Static analysis, secret detection and secure coding practices.
  • Deploy Policy enforcement, admission control and infrastructure security.

Overview

Terraform risk concentrates in three places: state files containing sensitive values, apply credentials with broad permissions, and unpinned modules or providers.

Why it matters

State is effectively a credential store, and apply permissions are usually close to administrative.

How it works

  1. 01Remote state is encrypted, versioned and access-controlled with locking.
  2. 02Plan runs with read-only credentials; apply is a separate, approved job.
  3. 03Modules and providers are version-constrained and checksum-locked.

Common tools

CheckovtfsecTerraform CloudOPATerraformAWSAzureGitLab

Implementation examples

hclEncrypted remote state
terraform {  required_version = "~> 1.9"  backend "s3" {    bucket         = "acme-tfstate"    key            = "prod/network.tfstate"    region         = "eu-west-1"    encrypt        = true    kms_key_id     = "arn:aws:kms:eu-west-1:111122223333:key/..."    dynamodb_table = "tf-locks"  }}
Encryption, locking and versioning are the baseline for shared state.

Best practices

  • Never commit state or `.tfvars` with secrets.
  • Separate plan and apply credentials.
  • Pin providers in the lock file.

Common mistakes

  • Using a single admin credential for both plan and apply.

Hands-on labs