How can I cache data using Azure Key Vault? - azure

I want to use Azure Key Vault for my PAAS application. Is there any way to cache the data instead of making calls every time to Key Vault to retrieve a key?

Here is a code sample to cache and proxy secrets, keys, and certificates from Azure Key Vault.
Links:
https://learn.microsoft.com/en-us/samples/azure/azure-sdk-for-net/azure-key-vault-proxy/ OR
https://github.com/Azure/azure-sdk-for-net/tree/master/sdk/keyvault/samples/keyvaultproxy/src
It is a pretty clean way.

Yes, any of the standard caching mechanisms will still work.
On first request, your app will look in cache first and won't find the value, so it will call KeyVault for value. You'll then store the value in cache so that the next time your application needs the value, it will be retrieved from cache.
You could do in memory, or ideally, something out of process, such as Redis.

Related

Azure Functions: Should I still use "KeyVault" (for Cosmos DB read-only access key) in a hot Function which has very HIGH LOAD of traffic?

I have one API on Azure Functions which has about 5k requests per second in the peak hours. Part of the function requires reading the Cosmos DB, and I currently use Azure Key Vault for the read access key.
Although the overall respond of the Azure Function is still acceptable, I wonder whether the usage of Azure Key Vault is a smart idea here. Because, to my understanding, it again makes additional round-trip of connection to the key vault every single time the function is called, which certainly contributes to the overall respond time.
Since it is a read-only key, would it be valuable in terms of performance if I omit the usage of the key vault here?

Azure Redis Cache, get induvidual keys statistics

I have a azure redis cache configured through APIM, i have requirement, as i need to generate below reports.
How many hits has been done for specific key.
What is the data size of specific key.
Last accessed time of specific key.
If i can get the above key details, then if keys gets deleted, will i still get the reports?
Or if getting this details from redis is not possible, then can i store these details somewhere in database.
Can anyone suggest on this pls?

Azure best practice

What is the best practice with windows Azure key vault. Is it a good practice to extract keys within the application every time we make use of it or it is good to set them in the OS environment variable.
It depends on what key. You should not be extracting master key, but the associated data keys to encrypt and decrypt.
There is no hard-fast rule here but you should consider the rotation of keys. If you need the keys to be rotated often you should consider pulling from Key Vault every time.
There are other times in makes more sense to pull once and cache locally. This could include your network latency being an issue so it's more cost-effective to pull once then cache. In this scenario, you will need some mechanism in place to force a new pull if/when the key is rotated.

Python Azure Timer Function with Durable Entity

I'm currently trying to work on my first Azure Function to act as an intermediary between Defender for Endpoints, and Azure Sentinel. It runs every 5 minutes, and collects data matching specific filters from the Defender API to then forward as custom logs to Azure Sentinel. Due to the authentication measures in place on Defender, I've set my script up using ADAL to do a device code logon the first time, then use the refresh tokens to do its scheduled running.
This is where I've come across the problem; since Azure Functions are serverless by design, holding this refresh token somewhere for the next invocation has proven troublesome. I'm trying to use Durable Functions, but the documentation for such a use case seems non-existent.
Are there other appropriate methods to store a singular variable across invocations of an Azure Function?
There are more than one way to solve the problem you are facing with holding the refresh token for every new invocation Azure Functions.
One way to solve the problem is by using a Azure Function Timer Trigger to request new access tokens and Azure Key Vault to store these tokens securely. We want to save them in Key Vault so the next time we invoke our function to refresh our tokens again, we will use the updated values and the next function will be able to obtain that value when invocated.
Check this document to access secrets from key vault.
Another way is enabling the token store in azure function and store it in blob storage. Check this document for more information.

Azure KeyVault key rotation

The Azure Storage sample code for key rotation demonstrates using multiple uniquely named Secrets. However, within KeyVault it is now possible to create multiple versions of a single Secret. I can see no reason why key rotation cannot be achieved using Versions and it seems on the face of it like it'd be easier to manage.
Can anyone offer any guidance on why you'd choose multiple Secrets over versions of a single Secret to support key rotation? And potentially any generally guidance on what Versions are intended for if not this?
Thanks!
Feel free to use a single secret and multiple versions for key rotation, depending on which SDK(s) you are using.
For our Node.js-based apps, we have configuration that points at the full KeyVault secret URIs.
Some secrets only point at the short URL for a secret (no version), so the app gets "the latest version".
Other secrets that need rotation will need the full URL to the version. We use Azure Table Encryption, for example; so each row in the table when encrypted uses a key wrapping key from KeyVault. The key wrapping key is a full KeyVault versioned URL, since you need that specific secret to decrypt the table data. Over time, different rows will point at different key versions.
For general scenarios, i.e. rotating a current version of a key to a new one, just built your configuration system and connection logic to support 2 keys at a time - if one fails, use the other; or consider a time-based logic.
Any approach is fine, but consider how nice and "clean" your story will be if you use versions over time instead of proliferating additional secret names.

Resources