[BUG] Clarification on Handling Escape Characters in Azure Key Vault Secrets

[bchr02]

trafficstars

Library name and version

Azure.Security.KeyVault.Secrets 4.5.0

Describe the bug

When storing RSA private keys or any multi-line secrets in Azure Key Vault, the newline characters are being escaped (\n), which leads to the secret being improperly formatted when retrieved. This causes issues when the secret is intended to be used in its original multi-line format, such as with RSA private keys for SSH connections.

This issue was first reported here: https://github.com/Azure/azure-sdk-for-net/issues/39434 but the explanation provided doesn't fully address the practical issue developers face. While it's true that a backslash (\) is an escape character in many languages, Azure Key Vault should store and retrieve secrets exactly as entered, without modifying the data. The escape character handling should be managed within the application code, not by the Key Vault service. This ensures that developers can securely and accurately store and retrieve secrets without additional transformations, which can lead to confusion and potential security risks.

Expected behavior

Azure Key Vault should store and retrieve secrets exactly as entered, preserving all formatting, including newline characters, without adding escape sequences.

Actual behavior

When storing multi-line secrets, such as RSA private keys, in Azure Key Vault, newline characters are being escaped (\n) in the retrieved secret. This results in a single-line string with \n literals instead of actual newlines, causing issues with parsing and using the secret in its intended multi-line format.

Reproduction Steps

1. Store a multi-line RSA private key in Azure Key Vault.
2. Retrieve the secret.
3. Observe that newline characters are escaped, leading to a single-line string with \n instead of proper newlines.

Environment

I am using the Secrets feature within Azure Container Apps

[jsquire]

Hi @bchr02. Thanks for reaching out and we regret that you're experiencing difficulties. The KeyVault service API is based on JSON payloads. The data sent and received by the client library is encoded to JSON or decoded from JSON using the System.Text.Json. Your secret is otherwise treated as an opaque value with no escaping or other inspection/alteration performed.

For example, following the KeyVault serialization logic shows that serialization/deserialization of a multi-line string value does not inject any escape characters or alter the form:

var multiLineValue = @"test
multi-line
thing

one more";

using var stream = new MemoryStream();
using var writer = new Utf8JsonWriter(stream);
        
writer.WriteStartObject();
writer.WriteString(JsonEncodedText.Encode("value"), multiLineValue);
writer.WriteEndObject();
writer.Flush();
    
using var doc = JsonDocument.Parse(Encoding.UTF8.GetString(stream.ToArray()));
var prop = (JsonProperty)doc.RootElement.EnumerateObject().First();

Console.WriteLine($"[{prop.Value.GetString()}]");   

If you are seeing changes made to your payload while not in transit, they are being made by something other than the Azure SDK client, such as by another tool within the Azure Container Apps secret feature or within the KeyVault service itself. This is not something that the Azure SDK package has insight into nor influence over and the maintainers of the library are unable to assist in troubleshooting them.

Your best path forward to find a root cause would be to open an Azure support request for Container Apps or inquire on the Microsoft Q&A site.

[github-actions[bot]]

Hi @bchr02. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.

[github-actions[bot]]

Hi @bchr02, since you haven’t asked that we /unresolve the issue, we’ll close this out. If you believe further discussion is needed, please add a comment /unresolve to reopen the issue.