Improve the error for nested getSecret() calls in parameter files

[polatengin]

Description

Fixes #19934

ARM supports Key Vault references as complete parameter values. It does not support them inside objects or arrays.

This change detects nested getSecret() calls earlier and reports BCP351 error.

Top-level getSecret() assignments and supported extension configuration assignments continue to work.

I've added tests for getSecret() calls;

• Object properties
• Arrays of objects
• Nested objects and arrays
• Conditional expressions
• Loop expressions
• Namespaced az.getSecret() calls
• Calls that include a secret version

Before the fix, all new tests failed with BCP338, after the fix, they pass and report BCP351 as expected.

The existing parameter-file and extension configuration tests also pass.

Checklist

• I have read and adhere to the contribution guide.

[github-actions]

Test this change out locally with the following install scripts (Action run 29541446351)

VSCode

• Mac/Linux

  bash <(curl -Ls https://aka.ms/bicep/nightly-vsix.sh) --run-id 29541446351

• Windows

  iex "& { $(irm https://aka.ms/bicep/nightly-vsix.ps1) } -RunId 29541446351"

Azure CLI

• Mac/Linux

  bash <(curl -Ls https://aka.ms/bicep/nightly-cli.sh) --run-id 29541446351

• Windows

  iex "& { $(irm https://aka.ms/bicep/nightly-cli.ps1) } -RunId 29541446351"

[JorgeDios]

Hi,

Thank you for the contribution.
The Pull Requests states "Fixes #19934" but it does only partially fix it. If I am not mistaken this PR does not add support for getSecret() on nested attributes or objects in parameter files.

[polatengin]

@JorgeDios

Thank you for the contribution. The Pull Requests states "Fixes #19934" but it does only partially fix it. If I am not mistaken this PR does not add support for getSecret() on nested attributes or objects in parameter files.

You are correct. This PR implements only the diagnostic improvement described in #19934; it does not add support for nested getSecret() calls.

This is currently constrained by the ARM deployment parameters contract. The official ARM deployment parameters schema and Resource Manager parameter file documentation defines each parameter entry as containing either a top-level value or a top-level reference. The reference structure documented for Key Vault secrets looks like this:

"password": {
  "reference": {
    "keyVault": {
      "id": "/subscriptions/.../providers/Microsoft.KeyVault/vaults/..."
    },
    "secretName": "password"
  }
}

ARM gives reference special meaning here because it is the complete value of the deployment parameter entry. A reference nested beneath a parameter's value, for example:

"credentials": {
  "value": {
    "password": {
      "reference": {
        "keyVault": {
          "id": "/subscriptions/.../providers/Microsoft.KeyVault/vaults/..."
        },
        "secretName": "password"
      }
    }
  }
}

is treated as ordinary object data and is not resolved as a Key Vault secret by ARM.

Until ARM adds support for Key Vault references within structured parameter values, Bicep cannot emit nested getSecret() calls while preserving ARM's deployment-time Key Vault resolution.

This PR only detects the unsupported placement earlier and reports the actionable BCP351 diagnostic instead of the opaque BCP338 emitter failure.