Azure / azure-sdk-for-js

This repository is for active development of the Azure SDK for JavaScript (NodeJS & Browser). For consumers of the SDK we recommend visiting our public developer docs at https://docs.microsoft.com/javascript/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-js.
MIT License
2.09k stars 1.2k forks source link

[keyvault-keys] Return the `x-ms-request-id` value in `CryptographyClient` results #29129

Open dhensby opened 7 months ago

dhensby commented 7 months ago

Is your feature request related to a problem? Please describe.

As part of our security posture, we aim to be able to correlate logged usage of our Azure Key Vault in our application with the logging from the Key Vault - this allows us to correlate logs between the two and surface any discrepancies, in turn allowing us to detect any unexpected usage of Key Vault Keys. At the moment, the CryptographyClient doesn't provide the correlation ID that the vault logs with the "result" objects that it provides.

Describe the solution you'd like

I would like all CryptographyClient result objects to contain the correlationId that the vault logs as part of its logging, so that the application layer can have access to this value as well.

Describe alternatives you've considered

At the moment it is possible to retrieve this value using the onResponse callback like so:

import { DefaultAzureCredential } from "@azure/identity";
import { KeyClient, CryptographyClient } from "@azure/keyvault-keys";

const credential = new DefaultAzureCredential();

const vaultName = "<YOUR KEYVAULT NAME>";
const url = `https://${vaultName}.vault.azure.net`;

const keysClient = new KeyClient(url, credential);

async function main() {
  let myKey = await keysClient.createKey("MyKey", "RSA");
  const cryptographyClient = new CryptographyClient(myKey, credential);

  const signatureValue = "MySignature";
  let hash = createHash("sha256");

  let digest = hash.update(signatureValue).digest();
  console.log("digest: ", digest);

  let correlationId;

  const [signResult, correlationId] = await cryptographyClient.sign("RS256", digest, { onResponse: (rawResponse) => {
      correlationId = rawResponse.headers.get('x-ms-request-id');
    } });
  console.log("sign result: ", signResult.result);
  console.log("correlation ID: ", correlationId);
}

It would be much nicer if this correlation ID was treated as a first-class property of the results that the library returns.

Additional context

N/A

github-actions[bot] commented 7 months ago

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

timovv commented 7 months ago

Hi @dhensby, thank you for opening this issue and sharing your scenario. We appreciate the feedback and suggestion.

I'll mark this as a feature request and put it in our backlog. For the time being, using the rawResponse callback as you are already doing would be our recommended approach if you need the value of this header.

As a bit of context, the x-ms-request-id header is metadata which isn't present in the service's specification of the response. In general, the properties that we expose in the response object are taken from the specification. I'm not sure that exposing this property directly on the response as you are suggesting would be in line with our design principles. But that's not to say that there wouldn't be another way of achieving what you're looking for. You have an interesting use case, and it would be interesting to understand if other people are using this header in a similar way.

dhensby commented 7 months ago

Thanks for the response and explanation. Absolutely makes sense and I did have the impression that this wasn't part of a formal specification, especially as the azure SDKs for other languages don't seem to provide any way to access this value (that I know).

From a security point of view, it is imperative that legitimate usage of a value in the vault can be correlated in the application layer so there is a way to detect misuse of the vault.

I'm not sure the best channel to raise this request, but the correlation ID should (IMO) form a part of the formal API and be a fundamental part of tracing vault usage for these kinds of audit trails.