Nested inline parameter properties of type SecureString cannot be provided to Az powershell cmdlets

[jeskew]

Something like the following example is not working with AZ Powershell New-AzResourceGroupDeployment.

type propertiesType = {
   @secure()
   foo: string
}

When the args are passed to bicep the following message is thrown:

InvalidTemplate - Deployment template validation failed: 'The provided value for the template parameter 'adminPassword' is not valid. Expected a value of type 'String, Uri', but received a value of type 'Object'. Please see https://aka.ms/arm-create-parameter-file for usage details.'.

As a workaround, I had to default to the default param.

It's a regular secure string passed from the az powershell command mentioned, something along the lines of

Powershell File

$templateFile = Join-Path $PSScriptRoot -ChildPath "infrastructure.bicep"

$adminUsername = "adminUsername" |  ConvertTo-SecureString -AsPlainText
$adminPassword = ".$.S0M3R4nD0MPwd#%" |  ConvertTo-SecureString -AsPlainText

$virtualMachine = @{
  Name = 'VMName'
  AdminUsername = $adminUsername
  AdminPassword = $adminPassword
  VmSize = 'Standard_E8_v5'
}

New-AzResourceGroupDeployment -Mode Incremental `
-TemplateFile $templateFile `
-Vm $virtualMachine `

Bicep file

type vmSize = 'Standard_E8_v5' | 'Standard_E8s_v5' | 'Standard_E16_v5' | 'Standard_E16s_v5' | 'Standard_E32_v5' | 'Standard_E32s_v5'

type virtualMachine = {
  name: string
  @secure()
  adminUsername: string
  @secure()
  adminPassword: string
  vmSize: vmSize
}

param vm virtualMachine

module resourceVMs 'module.bicep' = [for vm in vms: {
    name: vm.name
    params: {
      location: location
      adminUsername: vm.adminUsername
      adminPassword:  vm.adminPassword
      vmSize: vm.vmSize
    }
  }]

Something like this... I had to cut some bits and pieces for brevity and to remove the specifics of the project...

It's something related with the datatype. if it's a string works fine.. it can't be a secureString else it throws the error.
I was also glancing the PR mentioned above, and it seems that only addresses (I may be wrong) the output of secrets to the terminal.
The test cases only cover scenarios where the @secure decorator is used on param obj and not for user-defined typed properties, such as the case above.

Anyways, I tried also to decorate the whole type as @secure but didn't work either, same error...
I also tried to create a Powershell class object (strong typed) instead of the dynamic PSO... to force it.. same result.

Originally posted by @rmjoia in #11082 (comment)

[alex-frankel]

SecureString is actually no longer recommended for use in .NET, so we are not going to fix this one.

https://learn.microsoft.com/en-us/dotnet/api/system.security.securestring?view=net-8.0#remarks

Please let us know if we are misinterpreting this and we can consider re-opening.

[alex-frankel]

Re-opening after discussing with the PowerShell team. They clarified that SecureString is not a security boundary, but is the only way today to prevent accidentally emitting the value of these variables. The fix we need to make is most likely in the Deployments cmdlet.