How compliance.tf works
For anyone deciding how compliance.tf fits an existing Terraform workflow. It explains which part acts on which Terraform command, what each part checks, and where each one stops; Get started puts it into practice.
Compliance.tf serves the terraform-aws-modules you already use, built with the controls of the framework you pick, from a registry host per framework. Your organization can add operational rules that apply when the module is downloaded. For resources you write by hand, the compliance.tf provider for AWS checks the resource types its controls cover.
Where it acts
| Command | What happens | Part |
|---|---|---|
terraform init | Modules download from your framework's host with that framework's controls built in, plus your organization's operational rules if it has any. | Registry, operational rules |
terraform plan | A control the configuration breaks fails the plan with an error that names the control and links its page. With the provider, hand-written aws_* resources are checked too. | Module controls, provider |
terraform apply | With the provider, the check runs again before Terraform calls the AWS API. | Provider |
Nothing runs after apply. Drift and runtime findings stay with your CSPM and AWS-native tools.
The parts
Module controls
The controls are validation blocks and preconditions written into the module HCL, so they run inside terraform plan wherever Terraform runs: a laptop, CI or HCP Terraform. A public bucket ACL or an unencrypted RDS instance fails the plan before anything is created. You can read the checks in the downloaded module under .terraform/modules/.
- Checks: the inputs of modules that compliance.tf serves, against the controls the module enforces for your framework.
- Stops at: mapped controls that no module enforces; each framework page lists them apart, and they stay with your team. Modules compliance.tf does not serve pass through without controls; see Compatibility with terraform-aws-modules.
The host decides the framework; Registry endpoints lists them. Per module, you can turn controls on and off on the source URL.
Operational rules
Rules apply your organization's Terraform standards when the module downloads: lifecycle settings such as prevent_destroy and ignore_changes, provisioner removal, instance type restrictions. Controls carry the framework requirements; rules carry your own standards. Both arrive with terraform init.
- Checks: most rules change the module you receive rather than check it; a few, such as the instance type restriction, fail the plan when the configuration breaks them.
- Stops at: the modules you download. Hand-written resources get no rules. See Rules overview.
The compliance.tf provider for AWS
The provider runs the official hashicorp/aws provider unmodified and checks hand-written aws_* resources before Terraform calls AWS. You adopt it by changing the provider source and running one terraform state replace-provider. It comes with a built-in CIS baseline, free, without an account or a token.
- Checks: hand-written resources of the types its controls cover, at plan and again before apply. The default
soft_failwarns;hard_failstops the run on a violated deny control. - Stops at: resources inside child modules that do not themselves require the compliance.tf provider: modules that declare
hashicorp/aws, as every terraform-aws-modules module does, and modules that declare no provider at all. See the provider README.
CI checks
CI/CD integration runs the same plan in your pipeline. ctfkit adds a CI check that reports gaps and names the compliance.tf module that closes each one.
The organization console
Your organization's own host serves a Baseline and per-environment configuration, promoted between environments with an audit log. See Platform overview.
What changes in your workflow
- The source line. Each module points at a compliance.tf host instead of
terraform-aws-modules/.... Inputs, outputs and state stay the same. - A token.
terraform loginon your machine, a registry token in CI. See Registry tokens. - Plan failures you did not have before. Each one names a control. Fix the configuration, or turn the control off on the source with a reason in review.
- Nothing else. Your scanners, policy engine and CI keep their existing jobs. Compliance.tf puts the controls in the modules your plan is built from.
For vendor review, the Security & Trust page covers how modules are built and distributed, and the Trust Center holds SOC 2 reports, data handling policies and penetration test summaries.
Going back
Point each source back at terraform-aws-modules/... with the same version constraint and run terraform init. The plan shows no resource changes. The settings you added to satisfy controls stay on your resources; compliance.tf no longer checks them. To leave the provider, change its source back to hashicorp/aws and run terraform state replace-provider again.