In this article, I explain the key differences between Service Principal and Managed Identity in Azure. This is in continuation to the series that covers the difference between similar Azure resources. If you have worked on Azure deployments, you would have heard these two terms in the discussions. As part of any typical Azure deployment or architecture, we have to deal with either of them.

Service Principal

We can say the most relevant part of the Service principal is the Enterprise Apps section under Azure Active Directory. This is basically an application that will allow your user apps to authenticate and access Azure resources, based on the RBAC.

It essentially is an ID of an application that needs to access Azure resources. In layman’s terms, imagine if you have to assign certain access to your colleague so that he\she can access Azure resources and perform required tasks, you can use their email id as a way to authenticate the user.

What if there is a third-party application or a user application that needs to access Azure resources. How would you grant required permissions to that application? This is where Service Principal comes into the picture. A few of the use case scenarios can be:

  • Third-party monitoring application, such as Grafana or Prometheus needs to access Azure monitor data. We can create a service principal and use service principal properties (object-id, tenant id, secret) to integrate third-party applications with your subscription with the help of RBAC.
  • If you are running IAC deployments such as Terraform from Terraform cloud or GitHub.
  • Or you are using Azure DevOps to deploy the resources on Azure.

How is this done?

A service principal can be created using any method that Azure supports such as CLI, Portal, or Rest API. You can use the below azure cli command to create a service principal, you can export the appId, password and tenant information for later use.

az ad sp create-for-rbac -n "BLOG-SP-Test"

If you aren’t a big fan of CLI and want to use Azure Portal. You can check “Enterprise Application” section under Azure Active Directory:

Example:

If I want to set up Grafana to monitor my resources, I can use the values from the first screenshot and there you go, my setup is done:

While this seems all fair from a security perspective since we are not literally using the Azure administrative accounts anymore, there are also a few challenges involved in using SPs:

  • First, Someone needs to create the Service Principal objects, which could be a security risk
  • Client ID and Secret are exposed/known to the creator of the Service Principal
  • Client ID and Secret are exposed/known to the consumer of the Service Principal
  • Object validity is 1 or 2 years; I’ve been in situations where I deployed an App, which after one year stopped working (losing the token, which means no more authentication possibilities)

Where Service Principals are important and very useful from a security perspective, I also pointed out some challenges. The fact that there is administrative overhead (and potential security risk) involved is probably the biggest one.

That’s where Managed Identities come in.

Managed Identity

We can say that the Managed Identities are actually Service Principals and they are identical in the functionality and purpose they serve.

The only difference is, that a managed identity is always linked to an Azure Resource, unlike an application or 3rd party connector mentioned above. They are automatically created for you, including the credentials; big benefit here is that no one knows the credentials

There are two types of managed identities:

1.) System assigned; in this scenario, the identity is linked to a single Azure Resource, eg a Virtual Machine, a Web App, Function,… so almost anything. Next, they also “live” with the Azure Resource, which means they get deleted when the Azure Resource gets deleted.

2.) User Assigned Managed Identity, which means that you first have to create it as a stand-alone Azure resource by itself, after which it can be linked to multiple Azure Resources. An example here could be out of integration with the Key Vault, where different Workload services belonging to the same application stack, need to read out information from Key Vault. In this case, one could create a “read KV” Managed Identity, and link it to the web app, storage account, function, logic app,… all belonging to the same application architecture.

Example:

We can enable managed identity under the identity section of any resource. As you see in the below screenshot, we have an option to choose System assigned or User assigned.

Now I can assign this System Assigned Managed Identity any permission I want. For example, reading out an Azure Storage Account Access key or key vault secrets just like below example:

Notice how Azure Key Vault is expecting a Service Principal object here (where in reality we are using a Managed Identity).

Summary

As you would have understood so far a Service Principal can be looked at as similar to a service account-alike in a more traditional on-premises application or service scenario. Managed Identities are used for “linking” a Service Principal security object to an Azure Resource like a Virtual Machine, Web App, Logic App or similar. For a 1:1 relation between both, you would use a System Assigned, whereas for a 1:multi relation, you would use a User Assigned Managed Identity.

Advertisement