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.
| @Microsoft.KeyVault(SecretUri=https://<keyvault_name>.vault.azure.net/secrets/<secret_name>) |
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 them all the older ones for the sake of security.
- KeyVault Secrets Rotation Management
- Event-Driven KeyVault Secrets Rotation Management
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.
| dotnet add package Azure.Security.KeyVault.Secrets --version 4.2.0-beta.4 | |
| dotnet add package Azure.Identity --version 1.4.0-beta.3 |
The Key Vault package uses the IAsyncEnumerable interface. Therefore, also install this System.Linq.Async package.
| dotnet add package System.Linq.Async --version 4.1.1 |
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.
| func new --name BulkDisableSecretsHttpTrigger --template HttpTrigger --language C# |
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).
| public static class BulkDisableSecretsHttpTrigger | |
| { | |
| [FunctionName("BulkDisableSecretsHttpTrigger")] | |
| public static async Task<IActionResult> Run( | |
| [HttpTrigger(AuthorizationLevel.Function, "POST", Route = "secrets/all/disable")] HttpRequest req, | |
| ILogger log) | |
| { |
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.
| // Get the KeyVault URI | |
| var uri = Environment.GetEnvironmentVariable("KeyVault__Uri"); | |
| // Get the tenant ID where the KeyVault lives | |
| var tenantId = Environment.GetEnvironmentVariable("KeyVault__TenantId"); |
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, without explicitly providing the tenant ID, it throws the authentication error (line #4-6).
It happens more frequently on your local machine than on Azure.
| // Set the tenant ID, in case your account has multiple tenants logged in | |
| var options = new DefaultAzureCredentialOptions() | |
| { | |
| SharedTokenCacheTenantId = tenantId, | |
| VisualStudioTenantId = tenantId, | |
| VisualStudioCodeTenantId = tenantId, | |
| }; | |
| var client = new SecretClient(new Uri(uri), new DefaultAzureCredential(options)); |
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).
| // Get the all secrets | |
| var secrets = await client.GetPropertiesOfSecretsAsync() | |
| .ToListAsync() | |
| .ConfigureAwait(false); | |
| var utcNow = DateTimeOffset.UtcNow; | |
| var results = new Dictionary<string, object>(); |
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.
| foreach (var secret in secrets) | |
| { | |
| // Get the all versions of the given secret | |
| // Filter only enabled versions | |
| // Sort by the created date in a reverse order | |
| var versions = await client.GetPropertiesOfSecretVersionsAsync(secret.Name) | |
| .WhereAwait(p => new ValueTask<bool>(p.Enabled.GetValueOrDefault() == true)) | |
| .OrderByDescendingAwait(p => new ValueTask<DateTimeOffset>(p.CreatedOn.GetValueOrDefault())) | |
| .ToListAsync() | |
| .ConfigureAwait(false); |
If there is no active version in the secret, stop processing and continue to the next one.
| // Do nothing if there is no version enabled | |
| if (!versions.Any()) | |
| { | |
| continue; | |
| } |
If there is only one active version in the secret, stop processing and continue to the next.
| // Do nothing if there is only one version enabled | |
| if (versions.Count < 2) | |
| { | |
| continue; | |
| } |
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.
| // Do nothing if the latest version was generated less than a day ago | |
| if (versions.First().CreatedOn.GetValueOrDefault() <= utcNow.AddDays(-1)) | |
| { | |
| continue; | |
| } |
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).
| // Disable all versions except the first (latest) one | |
| var candidates = versions.Skip(1).ToList(); | |
| var result = new List<SecretProperties>() { versions.First() }; | |
| foreach (var candidate in candidates) | |
| { | |
| candidate.Enabled = false; | |
| var response = await client.UpdateSecretPropertiesAsync(candidate).ConfigureAwait(false); | |
| result.Add(response.Value); | |
| } | |
| results.Add(secret.Name, result); | |
| } |
And finally, store the processed result into the response object, and return it.
| var res = new ContentResult() | |
| { | |
| Content = JsonConvert.SerializeObject(results, Formatting.Indented), | |
| ContentType = "application/json", | |
| }; | |
| return res; | |
| } | |
| } |
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. In the next post, let's go further to make use of the event published by Azure Key Vault.