title: Why is a TFS secret not a SecureString?
body: <p>According to <a href="https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=tfs-2018&amp;tabs=classic%2Cpowershell#secret-variables" rel="nofollow noreferrer">documentation</a> you have to pass a secret in TFS 2018 to powershell like this:</p>
  <pre><code>Param(
     [string]$sauceArgument,
     [string]$secretSauceArgument
  )
  Write-Host No problem reading $env:SAUCE or $sauceArgument
  Write-Host But I cannot read $env:SECRET_SAUCE
  Write-Host But I can read $secretSauceArgument &quot;(but the log is redacted so I do not
             spoil the secret)&quot;
  </code></pre>
  <p>Passing it as string does not allow using the secret in credentials. I am only able to use it when I convert it via ConvertTo-SecureString -AsPlainText, which is supposed to be bad practise according to <a href="https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/convertto-securestring?view=powershell-5.1" rel="nofollow noreferrer">documentation</a>:</p>
  <pre><code>$Secure_String_Pwd = ConvertTo-SecureString $secretSauceArgument -AsPlainText -Force
  </code></pre>
  <p>If I change the input type from [String] to [SecureString], I get this conversion error:</p>
  <pre><code>Cannot process argument transformation on parameter 'secretSauceArgument'. Cannot convert the &quot;***&quot; value of type &quot;System.String&quot; to type &quot;System.Security.SecureString&quot;.
  </code></pre>
  <p>Does it really have to be converted at all? Does this mean using Secrets is bad practise?</p>
  <p>Update to clarify my question: I am able to pass secrets into powershell. I am not able to use secrets as credentials (only via ConvertTo-SecureString -AsPlainText -Force which is bad practise).</p>