Why Managed Identity?
Managed identities provide a secure and simplified way of authenticating and accessing resources without the need for hard-coding credentials. Correctly implemented managed identities eliminate the risk of exposing sensitive information such as passwords or client secrets in your code base. Leveraging this feature allows Azure to handle the lifecycle of the identity, automatically rotating credentials to minimize the risk of credential leakage and unauthorised access.
Incorporating managed identities in your Logic Apps is a best practice that aligns with the principle of least privilege: by which we mean, allowing your applications to access only the resources they need. This approach fortifies your application's security posture and ensures compliance with industry standards and regulations.
The Challenge
Managed identities are inherently tied to Azure resources. Consequently, when we attempt to use managed identities in local workflows, we hit problems as they are not available to the local environment and thus developers are unable to leverage managed identities for authentication.
To mitigate this problem, we need to use an alternative authentication method during development. We might consider using connection strings or service principles where supported, but this introduces a new challenge of maintaining two different authentication methods – one for cloud and one for local development. The need to maintain two different methods incurs additional operational overheads and you might ask how we can best optimise this. Let’s take an example of a workflow which uses a storage account connection and discuss two approaches which address the specific operational challenge of maintaining two connections.
Approach 1 – Using parameter to switch connection
In this approach, we maintain two connections strings the connections configuration file and use a parameter to switch between local & Azure. The connections.json file will look like the sample below with both managed identity and key based connection configurations.
Next, we add a parameter for the connection in the parameters.json file. The value of this parameter depends on the connection to be used.
Finally in the workflow file, use the parameter to switch the connection while executing the action.
Approach 2 – Maintaining separate connection files for local & Azure
In this methodology we’ll maintain two separate connection files instead of using a parameter to switch. One connection file for local and the second specifically for azure. The advantage of this approach is that there is no need to maintain a separate parameter file to switch connections. The default connections.json file will have the local settings that uses connection string.
And the second file connections.template.json (this could be any meaningful name) has the managed identity based connection.
When running the workflow from VS Code locally, the connection details from connections.json will be used. For deployment from the ADO pipeline, rename the template connection to connections.json as a step before creating the zip file for deployment.
Summary
The use of managed identities is best practice within development, but we have seen here the challenge that can be faced when attempting to leverage this functionality in the local environment. I have detailed two solutions which mitigate the challenge and there really is no one is better than the other choice. Rather, the choice of approach is a preference which may be driven by your preference. Regardless of the approach chosen both bring the clear advantage of reducing the need for manually editing connection settings between local development and cloud deployment.
Check out the following resources to learn more about managed identities:
https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview
https://learn.microsoft.com/en-us/azure/logic-apps/authenticate-with-managed-identity
Microsoft
