Support for Terraform

[ElinoraWhite]

This is tracking for adding support for Terraform HCL to PSRule originally discussed here microsoft/PSRule#907 by jbla9028.

Is your feature request related to a problem? Please describe.
It appears that psrule can review a ARM or bicep template from the documentation. It seems like the only open to review terraform is to review the resources after the terraform code has applied the infrastructure. Can we get native terraform support?

Passing a target folder, along with variables, can psrule review a user's terraform code for compliance?

Describe the solution you'd like

Describe alternatives you've considered
There are other solutions that will do this but psRule's syntax seems very easy to use, it would be great to leverage it with terraform.

Additional context

---

Continue reading the FAQ for details on in-flight support for Terraform.

---

If this issue is important to you please upvote the issue.
We plan to investigate this issue to determine if this is something that should be integrated into PSRule for Azure.

---

Updated: 2023-08-26

Some questions to add to the research effort:

• What do your current CI pipelines look like now?
• Do you generate a plan in your terraform pipelines for deployment?
• Do you use the azurerm or azapi providers?

[vishalgoyal16444]

Having PSRules support for terraform scripts hosted on a repository will be extremely useful to check for rules validation even before we create actual resources on Azure.

[vannela]

Terraform being used widely for Azure as well, support for validating is very useful.

[itpropro]

I think we should focus on the Azure tooling first. There are still multiple problems with bicep and ARM syntax.
First party tooling should be the focus and priority by now and maybe after Bicep 1.0, we can focus on third-party tools like Ansible, Pulumi or Terraform.

[trstroem]

Terraform really useful since often used in SAP on Azure implementations...

[MohnJadden]

Being able to test against Azure Policy would help eliminate a lot of Terraform headaches and errors. I bypass ARM entirely by using Terraform and avoid ARM wherever possible - TF is simply easier to use. We use azurerm exclusively.

[itpropro]

Being able to test against Azure Policy would help eliminate a lot of Terraform headaches and errors. I bypass ARM entirely by using Terraform and avoid ARM wherever possible - TF is simply easier to use. We use azurerm exclusively.

You are still using ARM REST APIs in the background, if you are using Terraform, just no ARM templates. If you don't like ARM template syntax, you can always use Bicep for simpler usage and much clearer syntax.

[core42cloudps]

Terraform is one of the popular tools for IaC. Support for Terraform will be very useful."

[rodney-almeida]

Most terraform iac scanning tools for Azure work with the AzureRM provider.
AzAPI provider uses the direct REST API payloads which are essentially ARM config and with AVM Terraform looking to move everything (where possible) to AzAPI leave us with a big gap in IaC scanning.
Hoping it would be an easier approach to get PSRule to work for AzApi provider only?

[polatengin]

Terraform Support - Design Proposal

Pre-flight analysis of Azure resources defined in Terraform, using the same rules that already work for Bicep and ARM templates. No new rules needed - Terraform resources will be converted to the same format rules already understand.

How it would work

Users generate a Terraform plan JSON file in their CI pipeline (something most teams already do), then point PSRule at it:

terraform plan -out=tfplan
terraform show -json tfplan > tfplan.json

# ps-rule.yaml
configuration:
  AZURE_TERRAFORM_PLAN_EXPANSION: true

PSRule detects the plan file, extracts Azure resources from it, converts them to ARM format, and runs all existing rules against them. Same results we'd get from Bicep - just from Terraform instead.

Provider support...

AzAPI provider

The AzAPI provider is the easiest starting point because it already speaks ARM natively. An azapi_resource looks like this:

resource "azapi_resource" "storage" {
  type      = "Microsoft.Storage/storageAccounts@2023-01-01"
  name      = "mystorageaccount"
  parent_id = azurerm_resource_group.example.id
  location  = "eastus"

  body = {
    sku        = { name = "Standard_LRS" }
    properties = { minimumTlsVersion = "TLS1_2" }
  }
}

The type field already contains the ARM resource type and API version. The body is already in ARM format. Conversion is nearly direct - we just need to reshape the structure slightly.

This matters because Azure Verified Modules (AVM) for Terraform are moving to AzAPI where possible, so coverage will grow over time.

AzureRM provider

The AzureRM provider uses its own attribute names (e.g., min_tls_version instead of minimumTlsVersion), so each resource type needs a mapping from Terraform attributes to ARM properties.

We can start with the most common resource types - storage accounts, key vaults, AKS clusters, virtual networks, SQL servers, container registries - and expand from there.

Unmapped resource types will be skipped with a warning, not an error. Partial coverage is better than no coverage.

Direct .tf file expansion

Like Bicep expansion today, we'd detect .tf files and automatically run terraform plan behind the scenes. This is more complex (needs terraform init, provider downloads, possibly credentials) and will only be pursued after AzAPI and AzureRM providers are stable.

How plan detection works

Both ARM parameter files and Terraform plan files are .json. We can distinguish them by content:

• ARM parameter files have a $schema property pointing to deploymentParameters
• Terraform plan files have a format_version property and a planned_values section

These checks are mutually exclusive - no risk of collision.

What the output would look like

A Terraform azapi_resource for a storage account gets converted to this (same format Bicep produces):

{
  "id": "/subscriptions/.../providers/Microsoft.Storage/storageAccounts/mystorageaccount",
  "type": "Microsoft.Storage/storageAccounts",
  "apiVersion": "2023-01-01",
  "name": "mystorageaccount",
  "location": "eastus",
  "sku": { "name": "Standard_LRS" },
  "properties": { "minimumTlsVersion": "TLS1_2" }
}

All existing rules see this exactly the same as a Bicep-expanded resource. No rule changes needed.

Assumptions/Limitations

• Users must generate the plan JSON themselves (no automatic terraform plan)
• No runtime property projection (e.g., principalId for managed identities)
• Sensitive values redacted by Terraform will be absent from analysis