This article aims to provide clarification on a particularly confusing concept within Azure, namely Service Principals and Managed Identities, which are components of the Azure Identity objects.
Azure Active directory provides three (3) types of native service account.
- Managed identities
- Services principle
- User-based service accounts (traditional service accounts/fake users)
The below table summarizes the recommendation.
| Service hosting | Managed identity | Service principal | Azure user account |
| Service is hosted in Azure. | Yes. Recommended if the service supports a Managed Identity. | Yes. | Not recommended. |
| Service is not hosted in Azure. | No | Yes. Recommended. | Not recommended. |
| Service is multi-tenant | No | Yes. Recommended. | Not recommended. |
Service principles
By utilizing a Service Principal, one can effectively circumvent the creation of “fake users” (referred to as service accounts in on-premises Active Directory) within Azure Active Directory for the purpose of authentication management when accessing Azure Resources.
By granting Service Principals Azure RBAC roles, it is possible to restrict their access to a particular subset of resources. One significant deviation from this RBAC principle is Azure Key Vault, which can be expanded by defining permissions with Key Vault Access Policies rather than Azure RBAC roles.
Service Principals are commonly utilized in scenarios such as
- Terraform IAC (Infrastructure as Code) deployments,
- Azure DevOps (defining a Service Connection from DevOps Pipelines to Azure),
- any other third-party application that necessitates an authentication token in order to establish a connection to Azure resources.
Managed Identity
With regard to functionality and use case, Managed Identities are virtually identical to Service Principals. Indeed, they qualify as Service Principals.
However, they are distinguished by the following: – They are permanently associated with an Azure Resource rather than an application or third-party connector; – They are generated automatically for you, complete with the requisite credentials; a significant advantage of this approach is that the credentials remain private.
There are two types of Managed Identities
- System assigned; the identity is associated with a singular Azure resource, such as a virtual machine, logic application, storage account, web application, function, or virtually any other item. Additionally, they “live” with the Azure Resource and are therefore deleted when the resource is removed. –
- User Assigned Managed Identity, which necessitates its initial creation as an independent Azure resource prior to its association with multiple Azure Resources. An instance that exemplifies this concept is when various Workload services associated with the same application architecture are required to retrieve data from Key Vault as part of an integration.
Summary
The purpose of this article is to clarify the application, distinction, and parallels between managed identities and service principals. An analogy between a Service Principal and a service account-alike could be drawn in a conventional on-premises service or application scenario. By “linking” a Service Principal security object to an Azure Resource such as a Virtual Machine, Web App, Logic App, or similar, managed identities are utilized. A 1:1 relationship would be represented by a System Assigned Managed Identity, whereas a 1:multi relationship would be represented by a User Assigned Managed Identity.
