feat(misconf): export raw Terraform data to Rego

[nikpivkin]

Description

Currently, Terraform configurations and other sources (CloudFormation, ARM, AWS Cloud, etc.) are converted into a common structure that is passed to Rego as input. This reduces the number of checks as there is no need to write separate checks for each provider. For example, the same AWS resources can be defined using Terraform or CloudFormation.

However, this approach has limitations:

• Access to arbitrary blocks and attributes of Terraform configurations is lost.
• Adding specific constructs such as tags becomes inconvenient or time-consuming.
• Users need to update Trivy to support new resources.

Users have experienced an inability to implement checks:

• for resource tags feat(misconf): Support additional terraform attributes  #5460
• for ephemeral blocks Prevent storing secrets in state by flagging these and where possible suggest solutions like ephemeral resources over data sources and write-only attributes over normal attributes #8713
• for k8s blocks Support for Kubernetes terraform resources #8506

Solution:

Add the ability to pass a raw configuration with little or no changes to Rego. At the first stage, the implementation will be only for Terraform, as it is the one that received requests from users. The architecture should be extensible to support other configuration formats in the future.

Planned changes:

• Add a flag that accepts a list of configuration types (only terraform at first) that are exported to Rego in raw form.
• Define a schema for representing terraform data in this format.
• Introduce a new selector type to filter checks.

[nikpivkin]

@simar7 I have a few ideas for the flag name:

• raw-config-scanners
• export-raw-config (I prefer this option)
• scan-raw-config

[simar7]

Sure export-raw-config as a config optional flag sounds good. What would be the values? "terraform,cloudformation"? As I mentioned earlier in the PR this maybe confusing to others. Ideally we should keep the selector and the value for this flag same.

To be clear, this is only so that we optionally render the raw config with a second pass right?

[nikpivkin]

The flag values will be a subset of all IaC scanner types except kubernetes, yaml, etc as they do not adapt the configuration. Why would using configuration names without the suffix raw for the flag be confusing? The flag indicates which types of configurations should be exported and scanned. It will be obvious to the user that if he wants to apply checks for raw TF and CF configurations, he needs to pass export-raw-config=terraform,cloudformation. But already in the check it is using terraform-raw as selector or schema type as it is a different data format.

I also thought and maybe scan-raw-config is also suitable, as Trivy is a scanner. Exporting the data is already internal implementation details.