Azure Managed Service Identity and Local Development
Instead of storing user credentials of an external system in a configuration file, you should store them in the Azure Key Vault. Before MSI (Managed Service Identity) you would have to store the credentials to use the key vault in the configuration file so this wasn’t really helpful. With MSI (Managed Service Identity) you do not have that problem anymore.
MSI
Managed Service Identity is basically an Identity that is Managed by Azure. Managed Identities are there in two forms:
- A system assigned identity: When the identity is enabled, Azure creates an identity for the instance in the Azure AD tenant that’s trusted by the subscription of the instance. After the identity is created, the credentials are provisioned onto the instance. The lifecycle of a system assigned identity is directly tied to the Azure service instance that it’s enabled on. If the instance is deleted, Azure automatically cleans up the credentials and the identity in Azure AD.
- A user assigned identity: is created as a standalone Azure resource. Through a create process, Azure creates an identity in the Azure AD tenant that’s trusted by the subscription in use. After the identity is created, the identity can be assigned to one or more Azure service instances. The lifecycle of a user assigned identity is managed separately from the lifecycle of the Azure service instances to which it’s assigned.
The main difference between the two forms is that this system assigned identity will exist as long as your application exist. The system assigned identity will also not be visible within the Azure Active Directory blade under the applications.
Assigning a MSI to an Azure Function
To enable the Managed Service Identity for an Azure Function you have to apply the following steps:
- Open the Azure Function in the Azure Portal
- Click on Platform Features and select “Managed service identity”
- Click “On” and click “Save”. In the background an Azure Application is created.
- Give the application the proper rights on the service you would like to use.
Using MSI in Code
To use the Managed Service Identity in code only two lines of code are needed in combination with the Azure Key Vault. Before using it you will have to add the following NuGet package: ” Microsoft.Azure.Services.AppAuthentication”
[FunctionName("Sample Function")] public static async Task<HttpResponseMessage> Run([HttpTrigger(AuthorizationLevel.Function, "post", Route = null)]HttpRequestMessage req, TraceWriter log) { log.Info("Function triggered."); string secretInfo= ConfigurationManager.AppSettings["kv:resource"]; //get secret for the application var azureServiceTokenProvider = new AzureServiceTokenProvider(); var kv = new KeyVaultClient(new KeyVaultClient.AuthenticationCallback(azureServiceTokenProvider.KeyVaultTokenCallback)); string secret = kv.GetSecretAsync(secretInfo).Result.Value; log.Info("Function finished."); return req.CreateResponse(HttpStatusCode.OK); }
MSI and local debugging
When developing an Azure Function and start on your local machine, you also want to use the Managed Service Identity. But how do you do that? You do not have a Managed Service Identity on your local machine.
But you do! Visual Studio uses the credentials of the logged in user of Visual Studio. So If you make use of the MSI while debugging locally make sure the user that is logged in into Visual Studio has the proper rights within Azure.
Nice article. Have you tried to use MSI and local debugging with an Azure SQL Database ?
As I explained in this stackoverflow post (https://stackoverflow.com/questions/57490505/query-azure-sql-database-from-local-azure-function-using-managed-identities) I can’t make it work which is strange as MSI and KeyVault works fine in local.
Did you try it without the nested user? Try to give the user access rights. directly
What do you mean by nested user ? Give access to the user directly without using a Azure AD Group ?
Hi everyone could you please provide me which permissions need for user to enable local debug for management identity