In the fast-paced world of cloud computing, achieving robust security can be a complex challenge. Managing and securing API secrets is a constant struggle for developers. Azure Managed Identity is a powerful tool designed to simplify this process by reducing the need for storing secrets and creating numerous app registrations. But what exactly is a managed identity, and why should app developers consider incorporating it into their workflows?
Azure Managed Identity offers the ability to authenticate to resources via Entra Id as a workforce identity using the privileged of code execution on an azure compute resource. In essence, by having code execution on the host you can access local API endpoints which can provide you with ID and Access tokens. This allows developers to steamline authentication to cloud services (such as Azure Key Vault, Azure SQL Database, and Microsoft Graph) without storing credentials in the application code. This approach enhances security by eliminating the need for hardcoded credentials, reducing the risk of credential leakage, and ensuring that access management is seamlessly integrated with Entra ID's robust identity management capabilities.
For app developers, using managed identities makes it easier to grant necessary permissions to applications, enhances security, and simplifies the authentication process. While the most common use case for Managed Identities is enabling access between Azure resources, such as an Azure Key Vault from an Azure App Service, it's less widely known how this technology works behind the scenes. Developers can also leverage these identities to authenticate to resources like Microsoft Graph or internal Enterprise Apps.
Managed Identities in Microsoft Entra Id
Under the hood, managed identities are represented as service principals in Microsoft Entra, appearing alongside your enterprise applications. This means you can manage them similarly, assigning permissions such as User.Read.All. These service principals are specialized accounts designed specifically to authenticate and authorize Azure resources, ensuring secure interactions within your cloud environment. Typically, managed identities have names that incorporate the resource name or a GUID (Globally Unique Identifier), making it easy to distinguish them from other service principals.
Token acquisition for managed identities happens directly on the Azure resources, remaining out of sight from end users. These identities obtain tokens via the Azure Instance Metadata Service, which allows them to authenticate securely without the need to store any credentials. Additionally, this approach provides comprehensive auditing and sign-in logs, akin to what you would expect from any enterprise application, ensuring robust security measures and traceability are in place.
Locating Your Managed Identity
You can find your Managed Identity under your Microsoft Entra's Enterprise Applications. By searching the name of your service or the client/app Id of the MI from the Azure resources. Here you can view audits and also view the API permissions that have been granted to the MI.
Managed Identities Lifecycle
Managed Identities in Azure come in two flavors: system-assigned and user-assigned, each with distinct lifecycle characteristics. System-assigned managed identities are created and tied to a specific Azure resource, such as a virtual machine, app service, or function app. When you enable a system-assigned managed identity for a resource, Azure automatically creates an identity in Microsoft Entra and links it to the resource. The lifecycle of this managed identity is directly tied to the resource it is associated with. If the resource is deleted, the system-assigned managed identity is also automatically deleted. This tight coupling simplifies management as the identity is only available for the lifespan of the resource, ensuring that unused identities do not persist beyond the resource's lifecycle.
In contrast, user-assigned managed identities are standalone Azure resources that can be created independently of other resources and can be associated with multiple Azure resources. These identities are managed separately and have their own lifecycle, distinct from the resources they are assigned to. This flexibility allows user-assigned managed identities to be shared across different services, making them ideal for scenarios where multiple resources need the same identity. The lifecycle of a user-assigned managed identity is managed explicitly by administrators, meaning it remains active until it is manually deleted, regardless of the lifecycle of the resources it is assigned to. This separation provides greater control and reusability, particularly in complex environments where consistent identity management across multiple resources is required.
Grant Graph API roles to Azure Managed Identity or Enterprise Application
Granting permissions to a Service Principal is not as simple as granting permissions to an App Registrions. Microsoft don't provide a nice user interface for us to use. However, don't be discouraged as we have Powershell or Graph Explorer to help us through the process.
Gather All The Guids
Unfortunately, one problem we have is that we need to aquire quite a few GUIDs before we can run the commands.
Microsoft Graph Permissions
Now, lets find the permission we want to assign to our Managed Identity using this permission reference. Here we must decide the least privileged for the API endpoints we would like to call. For this tutorial I chose to use the User.Read.All which in the table has an application permission ID df021288-bdef-4463-88db-98f22de89214.
This is only half the battle as we also need to determine the Entra Tenant's Microsoft Graph Id which is not constant between all our environments. We can find it using the following command GET https://graph.microsoft.com/v1.0/servicePrincipals(appId='00000003-0000-0000-c000-000000000000')?$select=id
Copy the ID of the service principal. This value should NOT be 00000003-0000-0000-c000-000000000000 (you have the Application ID if you get this).
Managed Identity Information
Service Principal Grant API
Let's run the command to grant the permissions. In my opinion, this endpoint requires too many GUIDs, making it challenging to ensure you have the correct GUID in the right place.
At a high level, we are configuring the Microsoft Graph Service Principal to assign one of its App Roles to your Managed Identity Service Principal. You'll need to insert three GUIDs into four different places.
- Microsoft Graph Service Principal ID into the URL
- Microsoft Graph Service Principal ID into the Body for
resourceId - Microsoft Graph App Role Id into the Body for
appRoleId - Managed Identity Service Principal Id in the Body for
principalId
POST https://graph.microsoft.com/v1.0/servicePrincipals/{Microsoft_Graph_SP_ID}/appRoleAssignedTo
Content-Type: application/json
{
"principalId": "b0d9b9e3-0ecf-4bfd-8dab-9273dd055a94", // This is your Managed Identity Service Principal ID
"resourceId": "7ea9e944-71ce-443d-811c-71e8047b557a", // This is the Microsoft Graph Service Principal ID
"appRoleId": "df021288-bdef-4463-88db-98f22de89214" // This is Graph Permission ID
}Verify Permission Assignment
GET https://graph.microsoft.com/v1.0/servicePrincipals/{MI_SP_ID}Need Some More Help?
Granting Microsoft Graph API permissions to a managed identity using REST endpoints provides a secure and streamlined way to manage access to Azure resources. By following this tutorial, you can effectively configure and verify the necessary permissions for your managed identities, ensuring seamless integration and secure authentication within your cloud environment.