An S3 backend
Mirrored into a data source, with the whole-state access cost stated first
terraform {
backend "s3" {
bucket = "my-state"
key = "network/terraform.tfstate"
region = "eu-west-1"
}
}Terraform Remote State Data Source Generator
Mirror a backend block into a terraform_remote_state data source. Read the first finding before you use it: this is one of the few Terraform features where the obvious approach has a security cost most people have not priced in.
Paste below, or drop a file anywhere on this panel
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Generate. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Examples
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
A local backend
Works on the machine that has both directories, and nowhere else
terraform {
backend "local" {
path = "terraform.tfstate"
}
}Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Using remote state to pass two values between configurations
The consumer gets read access to the entire producing state, which includes every generated secret in it. The convenience is real and so is the exposure.
Instead:Publish the values to a parameter store and read those instead. With HCP Terraform, use tfe_outputs.
Omitting the workspace argument when the producer uses workspaces
The data source reads the default workspace, succeeds, and returns another environment's values. Nothing warns you.
Instead:Add workspace = terraform.workspace, or use an explicit key per environment.
Removing an output another configuration reads
The consumer's plan fails on an unsupported attribute, and the error does not name the configuration that changed.
Instead:Treat any output another configuration reads as a public interface with a deprecation period.
There is no way to expose only some outputs
The data source downloads and parses the entire state file. Not the outputs, the whole thing.
Reading remote state means reading every secret in it
State holds the resolved value of every attribute in the producing configuration: generated passwords, private keys, tokens returned by APIs. A configuration that reads that state can read all of them, whether or not it touches them, and so can anybody who can run that configuration. The access is at the file, so it cannot be narrowed to the two outputs you wanted.
Publishing the values is usually better
Write the handful of values a consumer needs to SSM Parameter Store, Secrets Manager or an equivalent, and read them with an ordinary data source. The consumer gets exactly what it needs, access is audited per parameter, and the state stays private. With HCP Terraform, the tfe_outputs data source reads only the outputs and avoids the problem entirely.
Only declared outputs are readable
The data source exposes state.outputs and nothing else, so the producer must declare an output for every value a consumer needs. Referencing something that was never output gives an error about an unsupported attribute, which does not say that the other configuration is missing a declaration.
It is read at plan time, and nothing enforces the order
A consumer planned before the producer's first apply reads a missing state and fails. A consumer planned after the producer removed an output fails too. The dependency is real and invisible to both configurations, so it has to be written down wherever the pipelines are.
Workspaces are a silent failure
If the producer uses workspaces, its non-default state lives under a different key. A data source with no workspace argument reads the default one, succeeds, and returns another environment's values. Nothing reports a mismatch, so the wrong VPC id is simply used.
A local backend cannot be read from anywhere else
The path is resolved relative to wherever the consumer runs, so it works on the one machine that has both directories. In CI the file is absent and the data source fails with a path error, which reads like a checkout problem.
Related terraform tools
Terraform state mv Command Builder No plan, no undo Terraform State File Viewer Read it without uploading it Terraform dynamic Block Generator It is ingress.value, not each.value Terraform check and precondition Generator A failed check does not stop the apply Terraform variables.tf Generator From the var. references you already wrote Terraform Atlantis YAML Generator when_modified misses your modules
All 35 terraform tools