Managing the rotation of Azure storage account keys with Azure Function and Key Vault

Question

Having asked a question about Removing Secrets from Azure Function Config this Microsoft approach was recommended for managing the rotation of keys for Azure Storage Accounts and the keeping of those keys secret in Azure KeyVault

Note we are accessing Tables in an Azure Storage Account and Tables unlike Blobs and Queues do not support Managed Identity access controls.

The recommendation comes with some Azure Deplyment templates that would not run for me so I decided to create the resources myself to check my understanding of the approach. After trying to follow the recommendation I have some questions

Existing situation:

An existing function called "OurAzureFunction" that currently has the Storage Account connection string configured with the key directly in the Function config.
An existing storage account called "ourstorageaccount" that contains the application data that "OurAzureFunction" operates on

My understanding of the recommendation is that it introduces

"keyRotationAzureFunction", an Azure function with two Httptriggers, one that responds to event grid event for secrets that are soon to expire and one that can be called to regenerate the keys on demand.
"keyRotationKeyVault", a Key Vault that is operated on by the keyRotationAzureFunction.
An Event Grid subscription that listens to SecretNearExpiry event from "keyRotationKeyVault"

I have issues with understanding this approach. I can't see a better way but to collate the issues in this Stack Overflow question rather than with three individual questions.

Does keyRotationAzureFunction have the "Storage Account Key Operator Service Role" on "ourstorageaccount" so that it can regenerate its' keys?
What configuration does "OurAzureFunction" have that allows it to create a connection to ourstorageaccount? Is it the tagged secret in "keyRotationKeyVault"?
Is the value of the secret in "keyRotationKeyVault" not used just the tags related to the secret?

That article is a bit dated, and while it's supported the recommended approach is to use Managed Identity, which you can use with Azure Functions to, say, access Storage. See docs.microsoft.com/samples/azure-samples/…. You don't have to worry about rotating keys, and a password or token is never shared, making it easier to secure than a shared access token (and why we don't support managing storage keys in the new Key Vault SDK anymore). Would that work better for you? — Heath
Managed Identify didn’t work against Tables in a Storage Account. This question came after I asked a question about our current scenario and this as approach was recommended — Pat Long - Munkii Yebee
Question updated referencing earlier SO question and making the point that we are using Azure Table Storage — Pat Long - Munkii Yebee

Heath Heath · Accepted Answer · 2020-10-13T17:13:16

Yes, the function has to run as a principal that can rotate the keys, which that role provides. Key rotation can be kept as a separate role so that you can provide granular access to secrets to avoid leaks.
The function (rather, the principal) just needs "get" access to a secret used for generating SAS tokens (it's a special kind of secret where the value returned will change to generate new SAS tokens) that grants access to storage. The Key Vault must be configured to manage tokens for the Storage account. See a sample I just published recently at https://docs.microsoft.com/samples/azure/azure-sdk-for-net/share-link/ which I hope simplifies the problem.
The value of the secret is actually the generated SAS token for the storage account. The tags are used to figure out which secret to use for the storage account in case you have other secrets in your Key Vault, or even manage multiple function apps this way (you can identify the correct secret for the storage account key near expiry).

Managing the rotation of Azure storage account keys with Azure Function and Key Vault

2 Answers