Expansion & defaultValues

[dgcode]

Having a bit of an issue with running PSRule in that I constantly get errors related to defaultValues when testing my bicep templates.

Specifically, errors like the following:

ERROR Failed to expand bicep source '.\Templates\Microsoft.Insights\components\v2.0\azuredeploy.bicep'. Exception calling "GetBicepResources" with "3" argument(s): "Unable to expand resources because the source file '.\Templates\Microsoft.Insights\components\v2.0\azuredeploy.bicep' was not valid. An error occurred evaluating expression '[parameters('appInsightsName')]' line 78. The parameter named 'appInsightsName' was not set or a defaultValue was defined."

Which I'm assuming follows the WAF (I personally am, unable to find guidance on defaultValues). Lately I have been leaving specific parameters without defaultValues so as to enforce the person using the template to think about and provide a value before being able to deploy. This is not a deal breaker, more of a minor inconvenience.

The problem is whenever my template uses a secureString parameter:

ERROR Failed to expand bicep source '.\Templates\Microsoft.Compute\basevm\v2.0\azuredeploy.bicep'. Exception calling "GetBicepResources" with "3" argument(s): "Unable to expand resources because the source file '.\Templates\Microsoft.Compute\basevm\v2.0\azuredeploy.bicep' was not valid. An error occurred evaluating expression '[parameters('adminPasswordOrKey')]' line 398. The parameter named 'adminPasswordOrKey' was not set or a defaultValue was defined."

As far as I can tell, MS explicitly tells us to not to set defaultValues for any parameters that are denoted as secure:

• Don't provide default values for user names, passwords, or any value that requires a secureString type.
• Don't provide default values for properties that increase the attack surface area of the application.

ARM Template Best Practices | Microsoft Docs

To provide some context as we have (potentially) a slight more uncommon approach to using templates which may (?) be causing this issue.

• Our IaC tooling is a git repo started multiple years ago when ARM was the de facto standard for IaC in Azure
• To make our templates more modular, we created smaller/resource-specific templates and then joined them together into what we termed Deployments using linked templates
• Our templates can be versioned by creating specific file paths in our Templates folder (e.g. v1.0, see above file paths for examples)
• We have a PowerShell wrapper script and some custom PowerShell Modules that, in combination, validate our Deployments (resource group exists, all parameters provided, command line input for secureStrings, etc.)
• We have recently migrated to bicep and now use modules within our Deployments

So TLDR; Is there a way to suppress or workaround these errors?

[BernieWhite]

@dgcode Thanks for the question.

PSRule for Azure uses what we term expansion to be able to get a close to what would be deployed to Azure without actually doing any deployment.

To do this, just like if you actually deployed something to Azure we need to be able to fully resolve all parameters with a value.

With this in mind, you have a few options:

1. Define a default for the parameter in template/ Bicep module.
2. Define a Bicep test deployment. See Testing Bicep modules.
3. Provide placeholder defaults in PSRule configuration. See Required parameter default.

You are absolutely correct, you should not define a default for secure parameters, but we need to provide a placeholder for PSRule to use. So 1. is not applicable in your case. So consider option 2. or 3..

---

As an example, using a Bicep test deployment you would:

• Exclude azuredeploy.bicep from being processed by configuring the input.pathIgnore option. Explained in Configuring path exclusions.
• Define a test deployment such as azuredeploy.tests.bicep that then filled required parameters for the purpose of testing. Explained in Testing Bicep modules.

Example ps-rule.yaml:

configuration:
  # Enable expansion for Bicep source files.
  AZURE_BICEP_FILE_EXPANSION: true

input:
  pathIgnore:
  # Exclude bicepconfig.json
  - 'bicepconfig.json'
  # Exclude module files
  - 'Deployments/**/*.bicep'
  # Include test files for modules
  - '!Deployments/**/*.tests.bicep'

See example Bicep test code below. In most cases you only need a single test, however if you want to test optional parameters and conditions to improved code quality you absolutely can.

Also note the Key Vault test_keyvault doesn't exist, it's just a placeholder that it used to provide a secure string using the recommended way to provide secure values to parameters in Azure.

// Test SQL Logical Server module
targetScope = 'resourceGroup'

// ----------
// REFERENCES
// ----------

// A Key Vault for testing.
resource vault 'Microsoft.KeyVault/vaults@2021-11-01-preview' existing = {
  name: 'test_keyvault'
}

// A subnet for private endpoint connectivity.
resource subnet 'Microsoft.Network/virtualNetworks/subnets@2022-01-01' existing = {
  name: 'vnet-test/snet-test'
}

// A storage account for Defender features.
resource storage 'Microsoft.Storage/storageAccounts@2021-09-01' existing = {
  name: 'teststorage'
}

// ---------
// RESOURCES
// ---------

@description('A basic SQL logical server for testing.')
module test_basic '../main.bicep' = {
  name: 'test-sql'
  params: {
    sqlLogin: 'sqlAdmin'
    sqlLoginPassword: vault.getSecret('sqlAdmin')
    adminLogin: 'sql-admin-group'
    adminPrincipalId: '00000000-0000-0000-0000-000000000000'
    tags: {
      suppression: 'sql_basic'
    }
  }
}

@description('A SQL logical server with private endpoints for testing.')
module test_with_private_endpoints '../main.bicep' = {
  name: 'test-sql-with-pe'
  params: {
    sqlLogin: 'sqlAdmin'
    sqlLoginPassword: vault.getSecret('sqlAdmin')
    adminLogin: 'sql-admin-group'
    adminPrincipalId: '00000000-0000-0000-0000-000000000000'
    defenderForCloudStorage: storage.id
    subnetId: subnet.id
  }
}

@description('A SQL logical server with Azure AD auth only for testing.')
module test_with_aad_only '../main.bicep' = {
  name: 'test-sql-with-aad-only'
  params: {
    sqlLogin: 'sqlAdmin'
    sqlLoginPassword: vault.getSecret('sqlAdmin')
    adminLogin: 'sql-admin-group'
    adminPrincipalId: '00000000-0000-0000-0000-000000000000'
    defenderForCloudStorage: storage.id
    useAADOnlyAuthentication: true
  }
}

Some further examples are over here in our quickstart repo: https://github.com/Azure/PSRule.Rules.Azure-quickstart/tree/main/bicep/modules

You will notice, the two modules for key vault and storage each have a sub-directory .tests that contains main.tests.bicep file that points back to the parent directory.

---

Hopefully that answers your question.

[dgcode]

Excellent, thank you for the information Bernie. Must have missed this when I was reading through the documentation.