sec(iac/azure): scope nested access_policy detection to azurerm_key_vault, using an HCL parse rather than a fourth regex

[cristim]

Split out of LeanerCloud/cloud-commitments-cli#1817 after the nested-block detection produced three rounds of CodeRabbit findings on the same matcher. The resource-form ban that LeanerCloud/cloud-commitments-cli#1621 actually needs is unaffected and ships in LeanerCloud/cloud-commitments-cli#1817.

Background: why this is being separated

LeanerCloud/cloud-commitments-cli#1621 is about resource "azurerm_key_vault_access_policy" grants against an RBAC-enabled vault, which apply cleanly and then do nothing at runtime. LeanerCloud/cloud-commitments-cli#1817 closes that: the two grants are converted to azurerm_role_assignment, and a guard bans the resource form.

A second axis was added as hardening, detecting the nested forms (access_policy { } and dynamic "access_policy" { } inside azurerm_key_vault), which express the same inert grant. That axis has now been through three corrections:

1. Too narrow. The original matcher saw only the top-level resource form, so a nested block was reported clean. Reproduced.
2. Too broad. Widening it to catch nested blocks made it a prefix match, so access_policy_enabled = false and an unrelated access_policy = "metadata" both failed CI on valid Terraform. Reproduced: the guard exited 1 and named both lines.
3. Still too broad. Tightened to require a whole block header, it now matches access_policy { in any resource without checking the enclosing type. A valid non-Key-Vault resource carrying such a block fails CI.

Each fix was correct for the case it addressed, and each surfaced the next. That pattern is the signal to change approach rather than write a fourth regex.

Current state

Zero instances of either nested form exist in the tree (rg 'access_policy[[:space:]]*\{|dynamic[[:space:]]+"access_policy"' over terraform/ and iac/ returns nothing), and zero azurerm_key_vault_access_policy resources remain after LeanerCloud/cloud-commitments-cli#1817. So removing the nested axis loses no protection that is doing work today, while keeping it in LeanerCloud/cloud-commitments-cli#1817 blocks a security fix behind repeated rounds on optional hardening.

What to build

Detection scoped to the enclosing resource type: an access_policy block matters only inside azurerm_key_vault. Anywhere else it belongs to a different provider resource and is none of this guard's business.

Prefer a real HCL parse over a fourth text matcher. hclparse / hclsyntax in Go, or terraform show -json on a plan, gives the enclosing block type directly instead of inferring it from indentation and braces. A text matcher that tracks brace depth to infer scope is exactly the kind of thing that produces round four.

Verification bar

Both directions, and the negatives are where the previous rounds failed:

Must catch: access_policy { } inside azurerm_key_vault; dynamic "access_policy" { } inside azurerm_key_vault; both at arbitrary indentation.

Must ignore: an access_policy block inside any non-Key-Vault resource; access_policy_enabled = false; access_policy = "metadata"; a prose mention of the resource type inside a comment; .tf.json handling must stay fail-closed (exit 2) rather than silently clean.

Assert the reported file and line, not only the exit code. A guard that exits 1 with a blank or wrong message passes an exit-code-only suite, which the LeanerCloud/cloud-commitments-cli#1817 suite was found doing before it was extended.

[cristim]

Fourth finding on the same guard, from LeanerCloud/cloud-commitments-cli#1817, folded in here because it has the same fix.

Heredoc text is indistinguishable from a declaration. The line-based matcher flags resource "azurerm_key_vault_access_policy" appearing inside a heredoc, not only as a real resource block. CodeRabbit's suggestion was to require the resource label and opening brace and track heredoc state, or use HCL-aware parsing.

Not currently reachable: heredocs exist under iac/federation/*/terraform/{outputs,variables}.tf, but none contains that literal, and the only two occurrences of the string under terraform/ or iac/ are comments (aks/main.tf:106, cleanup-function/main.tf:32) which the guard already ignores.

That makes four rounds on this guard, every one correct, every one resolving to the same answer: parse HCL rather than match lines.

1. bare prefix missed the nested forms
2. widening made it a prefix match, so access_policy_enabled = false failed CI on valid Terraform
3. tightening to a whole block header left the enclosing resource type unchecked
4. heredoc text reads as a declaration

So the scope of this issue is now: replace the line matcher with an HCL parse (hclparse / hclsyntax, or terraform show -json) covering both the resource form and the nested forms, rather than adding heredoc state to a regex.

Add to the verification bar: a heredoc containing the banned literal must be ignored, and a real declaration adjacent to it must still be caught.