In a previous blog post, we have seen how to retrieve secrets from Azure Key Vault from an API Management policy. This works great, however, we might start to run into throttling due to the limitations which Key Vault imposes.
This might be due to having an API exposed which we need to call frequently, or because we retrieve secrets from Key Vault in multiple implementations, all of which adds to the restrictions. Luckily, API Management has another policy expression which helps us out here, namely the caching policy.
When working with Azure API Management, often we need to include secrets in our policies. For example, we may need to send a password in our authentication header, or to validate a key in a JWT token. There are several options to store these secrets. We could hardcode them into our policy, however this would mean anyone with access to our API Management instance could read them. An not just them, but also everyone who can look into our source control. because we deploy our policies as Infrastructure as Code.
The second option is to place the secret in a named value. This even provides us with the option to set the value as a secret, meaning it will not show the actual value in the overview.
However, anyone with access to API Management can still come into the instance, and untick the secret option, and grab the secret. Consequently, this is still not a good option, as we want the management of our secrets to be separate from our API Management administration. Therefor, we will instead store the secret in Azure Key Vault, and retrieve it in our policy.
When working with Azure, we should always put our secrets into a secure store, such as Key Vault. This ensures that we can limit who can see the values of our secrets, while still being able to work with them. How we work with these secrets is different over the various services, and in this article we will focus on Logic Apps, while other services will be explained in their own posts later on.
In Logic Apps we often will need some sort of secret, for example a subscription key for API Management, or a SAS key for Event Grid. In the scenario for this blog post we are going to send our secret to a RequestBin endpoint, so we can see that we indeed get the correct value.
NOTE: The explanation below is not officially supported by Microsoft! That said, we have been using this ourselves on several projects, and have seen no issues.
We use Key Vault extensively in our solutions, to store any secrets we might need. For example in an API through code, in Azure Functions via the application settings, or in a Logic App through a REST call. If you go to your secrets in Key Vault, you will notice that the link to the secret includes a version number, in the format of https://kv-we-retrieve-kv-secret.vault.azure.net/secrets/MySecretValue/80df3e46ffcd4f1cb187f79905e9a1e8.
Of course, this is great if we want to reference a specific version of a secret. However, often we will just want to reference the latest version, so we stay up to date even when the secret has been changed, for example because it is a rotating password.
It turns out, this is very easy, without the need to update the version number in all our applications whenever a new version is created. This is done by just omitting the version number from our link! So the will instead look like https://kv-we-retrieve-kv-secret.vault.azure.net/secrets/MySecretValue/.
Important to notice is the trailing slash ( / ), which needs to be included, otherwise you will just get a 404 error.