There was an announcement that you could refer to Azure Key Vault secrets from either Azure App Service or Azure Functions, without having to put their versions explicitly. Therefore, the second approach mentioned in my previous post has become now the most effective way to access Azure Key Vault Secrets.
With this approach, the reference always returns the latest version of the secret. Make sure that, when a newer version of the secret is created, it takes up to one day to get synced. Therefore, if your new version of the secret is less than one day old, you should consider the rotation. For the rotation, the ideal number of versions of each secret could be two. If there are more than two versions in one secret, it's better to disable all the older ones for the sake of security.
As there's no maximum number of secrets defined in Azure Key Vault, sometimes there are too many secrets stored in one Key Vault instance. In this case, finding old versions of secrets and disable them by hand should consider automation; otherwise, it needs too many hands. This sort of automation can be done by Azure Functions with the Azure Key Vault SDK. Let me show how to do so in this post.
You can find the sample code used in this post at this GitHub repository.
Azure Key Vault SDK
There are currently two SDKs taking care of Azure Key Vault.
As the first one has been deprecated, you should use the second one. In addition to that, use Azure.Identity SDK for authentication and authorisation. Once you create a new Azure Functions project, run the following commands to install these two NuGet packages.
The Key Vault package uses the IAsyncEnumerable interface. Therefore, also install this System.Linq.Async package.
NOTE: As of this writing, Azure Functions doesn't support .NET 5 yet. Therefore avoid installing 5.0.0 version of the
System.Linq.Asyncpackage.
We've got all the libraries necessary. Let's build a Functions app.
Building Functions Code to Disable Old Versions of Each Secret
Run the following command that creates a new HTTP Trigger function.
You've got the basic function endpoint with default settings. Change the HttpTrigger binding values. Leave the POST method only and enter the routing URL of secrets/all/disable (line #5).
Populate two values from the environment variables. One is the URL of the Key Vault instance, and the other is the tenant ID where the Key Vault instance is currently hosted.
Then, create the SecretClient that accesses the Key Vault instance. While instantiating the client, you should provide the DefaultAzureCredentialOptions instance as well. If the account logged into Azure is able to access multiple tenants, you should explicitly provide the tenant ID; otherwise, it throws the authentication error (line #4-6).
It happens more frequently on your local machine than on Azure.
Once logged in, get all secrets, iterate them and process each one of them. First things first, let's get all the secrets (line #2-4).
Now, iterate all the secrets and process them. But we don't need all the versions of each secret but need only Enabled versions. Therefore use WhereAwait for filtering out (line #7). Then, sort them in the reverse-chronological order by using OrderByDescendingAwait (line #8). Now, you'll have got the latest version at first.
If there is no active version in the secret, stop processing and continue to the next one.
If there is only one active version in the secret, stop processing and continue to the next.
If the latest version of the secret is less than one day old, the rotation is still necessary. Therefore, stop processing and continue to the next one.
Now, the secret has more than two versions and needs to disable the old ones. Skip the first (latest) one process the next one (line #2), set the Enabled to false (line #6), and update it (line #8).
And finally, store the processed result into the response object, and return it.
You've got the logic ready! Run the Function app, and you will see that all the secrets have been updated with the desired status. Suppose you change the trigger from HTTP to Timer, or integrate the current HTTP trigger with Azure Logic App with scheduling. In that case, you won't have to worry about older versions of each secret to being disabled.
So far, we've walked through how an Azure Functions app can manage older versions of each secret of Azure Key Vault while Azure App Service and Azure Functions are referencing the ones in Azure Key Vault. I hope that this sort of implementation can reduce the amount of management overhead.
Top comments (0)