Demystifying Service Principals – Managed Identities
Before zooming in on these, let’s take a step back and look at the different Azure Identity Objects we have available in Azure Active Directory today.
Azure AD Identity
Azure AD is the trusted Identity Object store, in which you can create different Identity Object types. The most common ones are Users and Groups, but you can also have Applications in there, also known as Enterprise Apps.
An example for each could be:
- Users: you create a user object in Azure AD, and from there allow the user to authenticate to the Azure Portal, to start using Office 365,…
- Groups: you define a security group in Azure AD, which can be used to specify permissions to SharePoint sites for example
- Enterprise Apps: using OpenIDConnect and OAuth, you allow a cloud-based application to trust your Azure AD for user authentication; the trusting app is known as an enterprise app object in Azure AD.
Most relevant to Service Principal, is the Enterprise apps; according to the formal definition, a service principal is “…An application whose tokens can be used to authenticate and grant access to specific Azure resources from a user-app, service or automation tool, when an organization is using Azure Active Directory…”
In essence, by using a Service Principal, you avoid creating “fake users” (we would call them service account in on-premises Active Directory…) in Azure AD to manage authentication when you need to access Azure Resources.
The Service Principals’ access can be restricted by assigning Azure RBAC roles so that they can access the specific set of resources only. There is one major exception to this RBAC rule, and that is Azure Key Vault, which can be extended by using Key Vault Access Policies to define permissions, instead of Azure RBAC roles. (to be 100% correct on this statement, there is actually a preview available since mid Oct 2020, allowing RBAC KeyVault access as well – check this article for more details).
Typical use cases where you would rely on a Service Principal is for example when running Terraform IAC (Infrastructure as Code) deployments, or when using Azure DevOps for example, where you define a Service Connection from DevOps Pipelines to Azure; or basically any other 3rd party application requiring an authentication token to connect to Azure resources.
An Azure Service Principal can be created using “any” traditional way like the Azure Portal, Azure PowerShell, Rest API or Azure CLI. Let me show you the command syntax out of Azure CLI to achieve this:
az ad sp create-for-rbac --name "pdtdevblogsp"
resulting in this outcome:
Copy this information aside; in the example of an Azure DevOps Service Connection, this information would be used as follows:
where you just need to copy the correct information in the corresponding parameter fields:
- Subscription Id = can be found from the Azure CLI under “/subscriptions/xxxxxx-xxxx-xxxx” format
- Subscription Name = can be found from your Azure Portal / Subscriptions; make sure you use the exact name as is listed
- Service Principal Id = appId from the Azure CLI output
- Service Principal Key = password from the Azure CLI output
- Tenant ID = tenant from the Azure CLI output
And using a Terraform deployment template file (or terraform.tfvars variable file) as an example, would use this information like this:
Terraform subscription service principal vars
subscription_id = "0a407898-c077-442d-xxxx-xxxxxxxxxxxx"
client_id = "3723bfcc-f0ba-4bba-xxxx-xxxxxxxxxxxx"
client_secret = "b9eab5cb-c1b0-46e6-xxxx-xxxxxxxxxxxx"
tenant_id = "70681eb4-8dbc-4dc2-xxxx-xxxxxxxxxxxx"
NOTE: The best recommendation I can give, is to store the Service Principal credentials in a safe way, like using Azure Key Vault, instead of a clear-text Notepad document or Terraform.tf file
And in a somehow similar way, you would use the same concept from about any other third party solution, keeping in mind that the technical parameter field names might differ a bit from what the Azure CLI command provides as output.
While this seems all fair from a security perspective, since we are not literally using the Azure administrative accounts (former service account concepts, remember…) 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 Identities are in essence 100% identical in functionality and use case than Service Principals. In fact, they are actually Service Principals.
What makes them different though, is: – They are always linked to an Azure Resource, not to an application or 3rd party connector – They are automatically created for you, including the credentials; big benefit here is that no one knows the credentials
Managed Identities exist in 2 formats: – System assigned; in this scenario, the identity is linked to a single Azure Resource, eg a Virtual Machine, a Logic App, a Storage Account, 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. – 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 an integration with 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.
Let’s walk through a quick demo scenario for both, using a Virtual Machine as Azure Resource:
- From the Azure Portal, select the Virtual Machine; under settings, find Identity
- Set Status as On, and save the changes
Switching to Azure Key Vault / Access Policies, we can now define this System Assigned Managed Identity having get and list permissions (or any other) for keys, secrets or certificates. For example reading out an Azure Storage Account Access key or similar.
Notice how Azure Key Vault is expecting a Service Principal object here (where in reality we are using a Managed Identity).
Similarly, let’s remove the System Assigned MI of the VM and use a User Assigned one in the next example (an Azure Resource can only be linked to one or the other, not both…):
- From the Azure Virtual Machine blade, navigate to Identity and switch the “Status” toggle button to Off.
- This will prompt for your confirmation when saving the settings
As you notice, the Managed Identity object gets immediately removed from Azure AD. Yes, security is key here…
- Wait for the deregistration of the object.
Remember that a User Assigned Managed Identity is a stand-alone Azure Resource, which needs to be created first, after which you can assign it to another Azure Resource (our VM in this scenario).
- From the Azure Portal, Create new Resource, and search for “User Assigned Managed Identity”
- click Create.
- Specify the Resource Group, Azure Region and Name for this resource.
- Confirm by clicking create and Wait for the resource creation to complete successfully.
- Once created, switch back to the Azure Virtual Machine, select Identity and select User Assigned
- Notice the Managed Identity you just created.
Select it and add it as a Virtual Machine User Assigned object.
Select another Azure Resource in your subscription, for example an Azure Web App, Logic App,… and once more select Identity from the settings. Below screenshot shows what it looks like for an Azure Web App Resource:
To complete the sample scenario, let’s go back to Azure Key Vault, and specify another Access Policy for this User Assigned Managed Identity:
- Select your Azure Key Vault resource, followed by selecting Access Policy from the settings.
- Specify the Key and/or Secret Permissions (for example get, list)
- Click “Select Principal” and search for the User Assigned Managed Identity you created earlier
After saving the changes, the result is that now both the Azure Virtual Machine as well as the Web App – having the User Assigned Managed Identity assigned to them – can read our keys and secrets from Azure Key Vault.
In this post, I wanted to clarify the use case, difference and similarities between Service Principals and Managed Identities. A Service Principal could 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, where for a 1:multi relation, you would use a User Assigned Managed Identity.
- Create your Azure Trial subscription
- Additional reading material on Service Principals
- Additional reading material on Managed Identities
As always, holler when having any questions firstname.lastname@example.org or @pdtit on Twitter