Azure-pipelines-tasks: [DeployAzureResourceGroup] Cannot convert the "********" value of type "System.String" to type "System.Security.SecureString".

[damienpontifex]

I am using the DeployAzureResourceGroup task and have a parameter in my deployment template of type securestring for a password. In VSO, I have set this as a variable with the 'secret' box checked.

When running the deployment, it fails with error:

Cannot bind parameter ''. Cannot convert the "**" value of type "System.String" to type "System.Security.SecureString".

I assume this is something to do with converting the variable to a powershell secure string, but I would assume that the way I have set it up is the best way to have it in VSO. Can a securestring type be used in this way? And if not, what is the way to utilise a securestring with the template and this build task?

[pavanadepu1]

I am looking into the issue and will get back to you soon with an update.

[pavanadepu1]

Currently it is a limitation, you cannot utilise a securestring with template and using this build task.
Thanks for the feedback. We will try to address your feedback.

[damienpontifex]

Great to know for now, but would be a good feature to be added in the future.

Thanks

[hrboyceiii]

I may have a "solution" to this. I'm not a fan simply because it smells of a script injection bug/vulnerability...however, it appears to work:

Where $(AdminPassword) is a protected environment variable, this takes the string and ensures it's a secure string passed to the template. Again, not sure how I feel about this but it worked.

[DivineOps]

I don't think closing this was a good idea. You should definitely be able to pass a securestring to the build task.

[mrvladis]

I am sorry, but what why it was closed?
What is the resolution?!

[bryanmacfarlane]

Re-opening for evaluation (or at least a conclusion write up)

[KrishnaAdityaB]

@mrvladis We closed this - as the issue opener was unblocked and a solution is shared already.
Let me provide the resolution write up.

IMO the solution shared by @hrboyceiii is the best one possible, because of below limitation.

Secure strings have to be decrypted in user space for the final consumption. i.e., _it can be decrypted only by the user who created it, and only on the machine on which it was created._
So, even if we pass a secure string as a release/build variable in the task - it will work only when the Agent is on the same machine where that secure string was created, and the agent is running with the same user context.
To have this Secure string work across machines, we have to use an explicit key for encryption and decryption. In this case, the Key too has to be passed as a release variable for the Agent to decrypt the secure string. This is equivalent to passing plain text.

Then how can we secure strings?
The secure release variables is the way. All the release variables marked secure are stored in a secure location by release management servers. And they are transferred securely over HTTPS connection. Once they are saved, they are given as plain text only to Agents - that is why, once the RD is saved, you can't see the secret as plain text though you uncheck the lock icon.
Agent machine is supposed to be secure. If it is not, even the Secure String is not of much help. As it has to be converted at some point into plain text for final consumption.

But my script requires a SecureString type:
Your script might take the input as SecureString because it has to pass the same to a cmdlet. I suggest, you take a String as input, convert it into SecureString and pass it to cmdlet. This input String can be passed in task as a secure Release variable.
Or use the solution that @hrboyceiii provided.
Or you can use both SecureString and Key. You can use the existing Release variables to store them.

@DivineOps SecureString is a .Net concept. Mapping of .Net types to Release variables doesn't make sense to me.
The Power Shell tasks can provide input fields of this type. But with current state, as you can't add/remove input fields dynamically - the task can't achieve this.
Please share your scenario, if I am missing something.

Refer: https://msdn.microsoft.com/en-us/library/system.security.securestring(v=vs.110).aspx
https://stackoverflow.com/questions/15580523/powershell-secure-password-to-work-on-any-machine