-
Notifications
You must be signed in to change notification settings - Fork 753
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nested inline parameter properties of type SecureString cannot be provided to Az powershell cmdlets #12481
Comments
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. |
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. |
Getting a similar error when executing
Az version: 12.3.0 |
@Oscar-Macdonald64 The original issue reported here has already been fixed - I've created Azure/deployment-stacks#190 to track is issue separately. |
Something like the following example is not working with AZ Powershell
New-AzResourceGroupDeployment
.When the args are passed to bicep the following message is thrown:
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
Bicep file
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 onparam 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)
The text was updated successfully, but these errors were encountered: