az keyvault secret set exposes value

[jurjenoskam]

It came to my attention (via a question I got from a colleague) that az keyvault secret set bluntly prints the secret value in cleartext to the output of the command (even if the secret was read from a file!).

I am aware this is a duplicate of #20858. The reason I am opening this issue anyway is that the suggestion there was to simply suppress the output of the command (via e.g. --output none) while the Key Vault API is being changed to no longer return the secret in its responses.

It is now more than half a year later, and the issue still occurs. Since printing a secret value in cleartext to stdout by default is a big violation of the Principle Of Least Astonishment, and it comes with a possibly significant security impact, I think it is warranted to introduce a workaround in Azure CLI so that it no longer prints the cleartext value of the secret.

Yes, changing the Key Vault API would also (and arguably better) solve this problem, but it is a design decision of Azure CLI to just dump the output of the response it gets to its API calls to stdout. Which means I think at least some of the responsibility is with Azure CLI to prevent this from happening.

[ghost]

Thank you for your feedback. This has been routed to the support team for assistance.

[yonzhan]

@evelyn-ys for awareness

[evelyn-ys]

@jlichwa Do we have any updates on server response removing secret plain text?

[jlichwa]

From REST API there is no other option than return it in plain text (if it is encrypted, then you will still need a key decrypt it then), which does not make sense. Changing behavior is min 3 years with current policy.

Is it a concern log output which can be hidden with output set to none. Operators regardless of if it is typed or from file (which operator will need access to this file), so it is not hiding it from operators. Considering that you will need secret value on get (which is 1000s times more common), the solution is to not blindly save everything to logs.

[jurjenoskam]

From REST API there is no other option than return it in plain text (if it is encrypted, then you will still need a key decrypt it then), which does not make sense

This would of course be true when getting a secret, but this issue is about setting a secret. If you're setting a secret in an API call, there's no need for the answer to contain the secret in cleartext.

the solution is to not blindly save everything to logs.

Right, so when can I expect the update to, say, Azure DevOps Pipelines so that it will no longer "blindly save all pipeline command outputs to logs"? But in all seriousness: the expected level of secrecy between and API client and the API provider is higher than the expected level of secrecy of output printed to stdout by a command that is not generally expected to return a secret value. While I'm generally very happy with the way Azure CLI provides its output (and it's query capability!), it is unfortunately the case that sometimes API responses unexpectedly (for the end user that is) contain values that they do not expect to be printed to stdout. In those cases, it would be nice if Azure CLI would redact out such information.

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @RandalliLama, @schaabs, @jlichwa.

Issue Details

---

It came to my attention (via a question I got from a colleague) that `az keyvault secret set` bluntly prints the secret value in **cleartext** to the output of the command (even if the secret was read from a file!). I am aware this is a duplicate of #20858. The reason I am opening this issue anyway is that the suggestion there was to simply suppress the output of the command (via e.g. `--output none`) while the Key Vault API is being changed to no longer return the secret in its responses. It is now more than half a year later, and the issue still occurs. Since printing a secret value in cleartext to stdout by default is a **big** violation of the Principle Of Least Astonishment, and it comes with a possibly significant security impact, I think it is warranted to introduce a workaround in Azure CLI so that it no longer prints the cleartext value of the secret. Yes, changing the Key Vault API would also (and arguably better) solve this problem, but it is a design decision of Azure CLI to just dump the output of the response it gets to its API calls to stdout. Which means I think at least some of the responsibility is with Azure CLI to prevent this from happening.

Author:	jurjenoskam
Assignees:	evelyn-ys
Labels:	`KeyVault`, `Service Attention`, `customer-reported`, `feature-request`, `Auto-Assign`, `Azure CLI Team`
Milestone:	Backlog

[navba-MSFT]

Adding Service team to look into this.