Failing to get AZURE_PARAMETER_DEFAULTS working

[AlexanderSehr]

Hey @BernieWhite, I hope you're doing well.

We recently introduced a new feature to the AVM CI that leds users pass secrets from a KeyVault into our test deployments. Part of that solution is to add a required @secure() parameter to the test file in question.

When running PSRule on those files, we noticed that it would complain about that parameter because it did not have a default. So far so good.

I found that you responded to a very similar issue and implemented a feature that allows you to define defaults for such parameters in the ps-rule.yml file.

Now, I wanted to use just that for our purposes and defined the following fallback values:

configuration:
  (...)
  AZURE_PARAMETER_DEFAULTS:
    backupManagementServiceEnterpriseApplicationObjectId: $GUID_PLACEHOLDER$
    azureDatabricksEnterpriseApplicationObjectId: $GUID_PLACEHOLDER$
    lighthouseManagedByTenantId: $GUID_PLACEHOLDER$

Matching our input parameters like this one:

@description('Required. The object id of the Backup Management Service Enterprise Application. This value is tenant-specific and must be stored in the CI Key Vault in a secret named \'CI-BackupManagementServiceEnterpriseApplicationObjectId\'.')
@secure()
param backupManagementServiceEnterpriseApplicationObjectId string

However, if I run the pipeline using that configuration, it appears that this setting is ignored:

Error: Failed to expand bicep source '/home/runner/work/bicep-registry-modules/bicep-registry-modules/avm/res/compute/virtual-machine/tests/e2e/waf-aligned/main.test.bicep'. Exception calling "GetBicepResources" with "2" argument(s): "Unable to expand resources because the source file '/home/runner/work/bicep-registry-modules/bicep-registry-modules/avm/res/compute/virtual-machine/tests/e2e/waf-aligned/main.test.bicep' was not valid. An error occurred evaluating expression '[parameters('backupManagementServiceEnterpriseApplicationObjectId')]' line 109. The parameter named 'backupManagementServiceEnterpriseApplicationObjectId' was not set or a defaultValue was defined."

I doublechecked if the settings file is in fact used, and it seems to be correctly configured.

Would you happen to know if I'm missing anything? In the docs it sounds like that should do the trick, yet here I am.

[BernieWhite]

Hi @AlexanderSehr, Thanks for reporting the issue.

I think this is a specific about how this option is loaded during expansion. It only operates from ps-rule.yaml found in the working path, which may not work based on you are overriding option: in your pipeline to a different option file.

You should be fine as a workaround to add this AZURE_PARAMETER_DEFAULTS key to a separate ps-rule.yaml file in the working path/ repo root leaving the other configuration values where they are.

But agree it's not ideal, confusing, and we'll work on a fix.

[BernieWhite]

@AlexanderSehr This should be fixed in PSRule for Azure v1.39.0 when it is released.

[BernieWhite]

@AlexanderSehr PSRule for Azure - Pre-release 1.39.0-B0072 includes this fix. Please double check this fix resolves your issue. I couldn't find your working branch to double check myself.

[AlexanderSehr]

Hey @BernieWhite, I was out of office the last 2 weeks so I was not able to validate it yet. Will do as soon as I caught up 💪

[AlexanderSehr]

Hey @BernieWhite,
just a quipck update on my part. I did retest the logic a few days ago - yielding the same results (ref).
Did I understand you correctly that the fix you implemented should've made the AZURE_PARAMETER_DEFAULTS usable from the file defined via the option: configuration? For example: option: "${{ github.workspace }}/${{ env.psrulePath}}/ps-rule.yaml" # Path to PSRule configuration options file - OR - was this instead addressed via an update to the docs that the feature is not compatible with the use of option:?

[BernieWhite]

@AlexanderSehr Thanks for the ref. Double checked with this and found a related issue. Can you please retest with the latest preview PSRule for Azure v1.40.0-B0147.

[AlexanderSehr]

@AlexanderSehr Thanks for the ref. Double checked with this and found a related issue. Can you please retest with the latest preview PSRule for Azure v1.40.0-B0147.

Hey @eriqua,
would you know where we can configure that in our setup?

[eriqua]

Hey @AlexanderSehr,
The job running PSRule reliability pillar is already using the latest released version of PSRule.Rules.Azure by default. Hence a rerun of your dev branch should be enough.

[AlexanderSehr]

Hey @eriqua, is that also true for preview versions? Interesting. WIll test.

[AlexanderSehr]

@BernieWhite, that seemed to have done the trick. Thanks for the update 💪
We should be able to close this issue.