Expose nested Terraform blocks in terraform-raw input

[kuzaxak]

Description

terraform-raw currently exposes top-level Terraform blocks and their attributes, but nested blocks are not exported to Rego. This prevents custom policies from inspecting common Terraform constructs such as terraform.required_providers, including provider version constraints.

Minimal example

terraform {
  required_version = ">= 1.5, < 2.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "= 6.37.0"
    }
  }
}

A custom terraform-raw Rego check can see the top-level terraform block and attributes like required_version, but it cannot inspect the nested required_providers block or the provider version value.

Expected behavior

terraform-raw should expose nested blocks under their parent block, so Rego checks can inspect required_providers and provider version constraints.

For example, policies should be able to reject exact provider pins such as = 6.37.0 while allowing bounded constraints like >= 6.0, < 7.0.

Actual behavior

The raw input exposes the top-level terraform block, but nested blocks such as required_providers are missing from the Rego input.

Related context

• Raw Terraform export feature: feat(misconf): export raw Terraform data to Rego #8877
• Initial implementation: feat(misconf): export raw Terraform data to Rego #8741
• Closed stale PR that seems to add nested block export via children: feat(misconf): export raw terraform blocks to Rego #9570
• Auto-closed issue created before noticing the contribution-policy workflow: feat(misconf): expose nested Terraform blocks in terraform-raw input #10698

It looks like #9570 is close to the needed behavior, but it was closed as stale rather than merged. Would the maintainers accept a refreshed version of that approach?

[spinningarrow]

Exposing nested blocks is super useful, even essential I'd say. There's a whole host of checks missing if we're only looking at top-level keys. Can we revive #9570 somehow?

[nikpivkin]

Thanks for the input, and for reviving this @kuzaxak @spinningarrow.

Before reviving #9570 we want to get the exported structure right, because it becomes part of the public terraform-raw input and is hard to change later. The previous attempt had a few design issues we would rather not lock in (overloaded name, dropped blocks that carry labels such as provisioner "local-exec", and a schema that gave up on nesting depth).

To design the structure around real needs rather than guesses, could you share the concrete checks you want to write that are not possible today? For each case it helps to have:

• a minimal Terraform snippet,
• what the check should flag,
• the field or nested block you need to reach.

A few examples to show the kind of detail we are after (please add your own):

• terraform.required_providers: reject exact version pins like version = "= 6.37.0" while allowing bounded ranges.
• flag aws_security_group with an ingress block open to 0.0.0.0/0.
• presence of provisioner "local-exec" on a resource.
• lifecycle { prevent_destroy = true } requirements.

We are leaning toward a uniform, recursive block model where every block (top level and nested) has the same shape, so the same Rego idiom works at any depth. The use cases you provide will directly validate whether that shape is ergonomic enough.