Azure Managed Identity vs Service principal

In this short article, I wanted to put some light across the confusing concepts in Azure AD around Service Principals and Managed Identities.

We often comes across two ways of authenticating applications and resources with Azure AD while working in Azure cloud.

Now let’s check in detail what are they and how they differ and what advantages one have over another.

Managed identities as the name suggests are fully managed identity objects created in Azure AD, where a source system can obtain a token from Azure AD without the source owner having to manage credentials. They are in a way a special category of service principal .

Now let’s look at some of its salient features

• They have 1:1 relationship with Azure resource it is associated with .
• They are tied to the lifecycle of Azure resources.
• They are automatically created for you, including the credentials
• They can be located at Azure portal > AD blade > Enterprise app > managed identities
• They have auto password reset in 46 days by Microsoft. No one can see its password ( not even the Global admin!)
• When the managed identity is deleted, the corresponding service principal is automatically removed.

So now, we know what it is & what are their attributes in the world of identity. Now, let’s look at how it works.

• When a managed identity is assigned to a resource , the source system obtains access token from the MS token endpoint and is presented to the target system for authentication.
• The target system used it to authenticate (identify) and authorize the source system before allowing access.
• If the target service supports Azure AD-based authentication it accepts an access token issued by Azure AD.

Interesting right ?

Let’s move on…

Now we all know, any service in Azure provide us with a control plane as well as a data plane. In the control plane, we create resources, and in the data plane we access them. For example, we create a SQL DB in the control plane, but we query it in the data plane.

Once the target system accepts the token for authentication, it can support different mechanisms for authorization for its control plane and data plane.

All of Azure’s control plane operations are managed by Azure Resource Manager and use Azure Role Based Access Control. In the data plane, each target system has its own authorization mechanism. Azure Storage supports Azure RBAC on the data plane. For example, applications using Azure App Services can read data from Azure Storage, and applications using Azure Kubernetes Service can read secrets stored in Azure Key Vault.

Now what are the caveats in using a Managed identity for your Azure resources ?

• Currently not all Services support Managed Identity . Yes, unfortunately MIs are not supported by all the Azure resources today .We can find the services that it supports in the bottom of the article.
• They cannot be shared with multiple resources , so it makes it not ideal for resources that need group management
• Managed identities do not get updated when a subscription is moved/transferred to another directory. There are some workarounds for this which is described here

Now it is important to note that there are two types of Managed identities . They are System assigned and User assigned.

System assigned : Here, the identity is linked to a single Azure Resource e.g. a Virtual Machine, a Storage Account, App service etc. They have the same lifetime as that of the resource associated and they get deleted when the Azure Resource is removed.

The benefit here would be that, there is no need to manage the credentials, embed it in a code or will not create orphan identifies once the parent resource is deleted.

User Assigned : Here, the identity need to be created first before it can be linked to multiple Azure Resources. Yes multiple — this contradicts with the statement I made above that MIs have 1:1 to relationship. The User assigned MI is unique in that way so can be linked with multiple resources of the same architecture like an application backend reading a secret from Keyvault , it could be a web app, a storage account or an Azure function for automation . The benefit here would be that, the identity doesn’t gets deleted with the resource so it can be re-used for the same use case or another use case afterwards. ( We must follow a right naming convention so that we identity for which purpose it was created earlier )

Taking reference from the MS articles, below are the comparison between two

Service Principal

A Service Principal is analogous to a service account in a traditional on-premises application or service environment. The formal definitions from Microsoft explains service principal as “ An Azure service principal is a security identity used by user-created apps, services, and automation tools to access specific Azure resources.”

SP only needs to be able to do specific things, unlike a general user identity. It improves security if you only grant it the minimum permissions level needed to perform its management tasks.

Service principal helps us to get rid of false user accounts that we create in the active directory world which is then used to authenticate using user name and password( basic authentication). Now that Microsoft has stopped the support of basic authentication on their important services like Exchange online the use of Service principals will become paramount to manage the applications connecting the o365 services to invoke modern authentication flows.

Now let is see the salient features of Service Principals

• The Service Principal access can be restricted by assigning Azure RBAC roles so that they can access the specific set of resources only
• Called as Enterprise Application in the Azure AD context and can be registered through portal, CLI , PowerShell , REST API etc.
• They have one to many relationship
• They are independent of the resource lifecycle and can be created ahead of assignment to resources.
• Can be located at Azure portal > AD blade > Enterprise app
• Uses client secrete or certificate with user managed expiry.

Service principals works the same was as Managed Identity, the service can use it to get Access tokens from the Azure AD to authenticate and we can assign RBAC permissions in the control place to provide Read / Write capabilities for the Service principal.

Actually as we discussed earlier, the app ID and client secret acts a username and password here but we have decoupled it from the On prem AD and at the same time without creating user accounts. The client secret of the Service principal need to the protected the same way we protected the service account passwords in the on premises world

It is also worth to note that a Service principal terminology is also used in the context of registering application in Azure AD and used interchangeably to denote applications published by other companies in the AAD gallery that can be used within your organization. Your own applications will also be represented in the Enterprise Applications blade as Service Principals, which are instantiations of your applications in the tenant. For third-party apps, you’ll only have a service principal in Enterprise applications. We will cover more on this later on another article.

Below picture depicts the components of a Service principal registration

Now that we know what Service Principals are and how they are created ( I’m not explaining the creation of SPs using Portal or CLI as it is very well explained in Microsoft docs, please refer the link references under the bottom section) , let us talk about some of the challenges and how to overcome them

• The app id and client secret need to be protected in a secure place since malicious actors getting them can use it to their advantage.
• Rotation of the client secret following security guidelines or certificate sometimes require redeploying the code of making changes in the production environment
• The expiry of the client secret of certificate need to be appropriately taken care else the authentication can break

The best way to protect the secrets would be to store them in the Azure Keyvault for future use with RBAC for the application/ DevOps team. It provides audited store for the client secret . Wherever it is possible, the application to be configured to read the secret from the Keyvault instead of hardcoding the client secret within the code or application. If it needs to be hardcoded, ensure it is encrypted while making API calls and also the code is accessible only to the admins/ owners with auditing enabled .

This is where Managed identities comes for rescue , which relieves us from these credential management and rotation overheads.

Security Tip !!! Enable logging

From a security perspective, it will be always good to enable logging for the usage of Managed identities and Service principal as they provide a great visibility for SOC teams esp. in the context of recent SolarWinds supply chain attack.

So, how to we enable it and what it gives us ?

It can be enabled from the Azure AD diagnostic setting, and we could store it in Log analytics workspace or (and) send it to a SIEM application through EventHubs.

It gives us visibility to the otherwise hidden API calls between the application actors, both interactive and non-interactive and can be used to identify the threat vectors like illicit grant attacks , track malicious app etc. . We will discuss more on this in another article.

Microsoft document references for further exploration

1. https://docs.microsoft.com/azure/active-directory/develop/app-objects-and-service-principals
2. https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview?
3. https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities
4. https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal

Some additional tips !!

1. Managed Identity was previously called as Managed Service Identity.
2. Service principals are different from SPNs ( Service principal names) so be careful when you call both as SPNs.

Thats all for now . See you in next article !