Hello Everyone,
Lately, I’ve tackled a task at work involving a nifty solution for a department. They were in need of a system that could tidy up their Azure storage account container by removing files older than 30 days. The key players in this solution were:
- Function App (on Consumption Plan)
- User-Managed Identity
Instead of delving into the nitty-gritty of setting up these resources, I want to shine a light on the authentication process within the function app. Specifically, I’ll walk you through how I seamlessly employed a user-assigned managed identity to establish communication with the department’s storage account.
User Assigned Managed Identity Permissions
To get the gears turning smoothly, I had to bestow the ‘Storage Blob Contributor’ role upon my managed identity, granting it the necessary permissions over the target storage account. Following that, I ensured that my function app was well-equipped by adding the ‘Website Contributor’ role.
C# Function
I whipped up the function in C#, and now, let me give you a glimpse of the code where the enchantment unfolds—the authentication setup using the managed identity.
1 2 3 4 5 6 7 8 |
var tokenCredential = new DefaultAzureCredential(); BlobServiceClient blobServiceClient = new BlobServiceClient( new Uri($"https://{storageAccountName}.blob.core.windows.net"), tokenCredential ); |
Here, the DefaultAzureCredential
effortlessly takes care of authentication, ensuring a smooth interaction between your function and the storage account, making the whole process a walk in the clouds.
Here’s a breakdown of how DefaultAzureCredential
works:
- Environment Variables: It first checks environment variables for credentials. If your application is running in a development environment, you might have environment variables set up for your Azure authentication details.
- Managed Identity: If no environment variables are found, it automatically falls back to Managed Identity credentials. In your case, since you mentioned using a user-assigned managed identity, the
DefaultAzureCredential
would leverage that identity for authentication. - Visual Studio Code (VS Code) Integration: If you’re developing in Visual Studio Code, the credential can also use the Azure Identity extension to simplify the authentication process.
- Azure CLI Integration: If the Azure CLI is installed and configured on the machine,
DefaultAzureCredential
can use the credentials obtained by the CLI.
By using DefaultAzureCredential
, you don’t have to explicitly manage and pass around authentication details in your code. It adapts to the context in which your application is running, making it more flexible and easier to work with in various development environments.
Function App Configuration
To complete the token retrieval for the aforementioned setup, I had to integrate the ‘Client ID’ of my user-assigned managed identity into the function app configuration section, specifically under ‘Application Settings.’ The crucial identifier needed to be named ‘AZURE_CLIENT_ID,’ with its value set to the client ID retrieved from the user-assigned managed identity.
Conclusion
With this configuration in place, I successfully established seamless communication between my function app and the target storage account, all without the need for cumbersome SAS keys. The process was streamlined, allowing for efficient removal of files as required.