There was anannouncement that you could refer toAzure Key Vault secrets from eitherAzure App Service orAzure Functions, without having to put their versions explicitly. Therefore, the second approach mentioned in myprevious post has become now the most effective way to accessAzure 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 therotation. 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 inAzure 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 byAzure 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 thisGitHub repository.

Azure Key Vault SDK

There are currently two SDKs taking care of Azure Key Vault.

• Microsoft.Azure.KeyVault
• Azure.Security.KeyVault.Secrets

As the first one has been deprecated, you should use the second one. In addition to that, useAzure.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 theIAsyncEnumerable interface. Therefore, also install thisSystem.Linq.Async package.

NOTE: As of this writing, Azure Functions doesn't support .NET 5 yet. Therefore avoid installing 5.0.0 version of theSystem.Linq.Async package.

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 newHTTP Trigger function.

You've got the basic function endpoint with default settings. Change theHttpTrigger binding values. Leave thePOST method only and enter the routing URL ofsecrets/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 theSecretClient that accesses the Key Vault instance. While instantiating the client, you should provide theDefaultAzureCredentialOptions 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 theauthentication 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 onlyEnabled versions. Therefore useWhereAwait for filtering out (line #7). Then, sort them in the reverse-chronological order by usingOrderByDescendingAwait (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 theEnabled tofalse (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 fromHTTP toTimer, or integrate the current HTTP trigger withAzure 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 eachsecret of Azure Key Vault whileAzure App Service andAzure Functions are referencing the ones inAzure Key Vault. I hope that this sort of implementation can reduce the amount of management overhead.