Authenticating with Azure - Security principals explained

So you want to run some infrastructure as code on a GitHub actions or perform some other automation against Azure. The first step is to have an identity which can authenticate with Azure and has been granted the permissions to do what is required.

It sounds easy in theory but there are quite a few moving parts and different options, each with their pros and cons. To effectively navigate and understand this problem space you need to understand app registrations, user assigned managed identities and service principals which can be confusing for those unfamiliar with Azure. The goal of this blog post is to explain them and lay out some best practices on how to use them.

Entra ID

The key system which controls all authentication and authorization within Azure is Entra ID, so that is where we start.

There are different types of objects in Entra ID which are essentially an identity which can be assumed to perform actions with:

• User

• Service Principal

• Managed identity

Their differences are how they are mainly around how they are created and managed. These are also known as security principals.

Security principals can be assigned permissions, because they exist inside your Entra.

Security Principal types

We won’t bother covering Users in this article as we are interested in programatic access to Azure, so we will just be covering the two types of Service Principals in Entra, Managed Identities and App Registration based Service Principals. (There is also a third type of Service Principal which is considered legacy which is a Service Principal without an associated app registration.)

Managed Identities

Let’s start with Managed Identities, they are created via a resource in Azure. There are 2 types, User Assigned Managed Identity and System Assigned Managed Identity. When created, they will automatically create and manage a Service Principal inside your Entra Tenant which can be assigned permissions.

User Assigned Managed Identities are an Azure Resource type. They can be created with the following command:

az identity create -g <RESOURCE GROUP> -n <USER ASSIGNED IDENTITY NAME>

System Assigned Managed Identities are a managed identity created for an Azure Resource. For instance, enabling Managed Identity on an App Service will enable a default or system assigned managed identity to be created.

And to see both sides of this in the portal we can see the MI as a resource in our Resource Group

And under the Enterprise applications we can find the Managed Identity Service Principal.

 

And as with other types of Service Principals, credentials are not specified directly on this service principal. It’s just the identity which roles in Azure can be assigned to.

App Registration based Service Principals

The other type of Service Principals which can be created in Entra is App Registration based Service Principals. There is a 3rd type which is considered legacy which is a Service Principal created without a MI or App Reg, which are similar to service accounts in the on premises active directory.

Principals to login to Azure to perform automation/deployments etc.

Service principals start with creating a different type of Entra object, an Application Object. This Application Object is a blueprint defining:

• How the service can issue tokens in order to access the application

• The resources that the application might need to access (eg, MS Graph etc)

• The actions that the application can take

App registrations are not a security principal though, and as such, they cannot be used to authenticate into an Entra Tenant.

This is where service principals come in, they are a type of Entra object created inside a tenant, which can be assigned roles within that Tenant.

As you can see in the above the dark blue user icons are service principals and are associated with an app registration.

To step this out using the Azure CLI you would perform the following steps.

az ad app create --display-name my-app-registration --sign-in-audience AzureADMyOrg

This will create an app registration which is limited to just your organisation/the same entra tenant.

az ad app create --display-name my-app-registration --sign-in-audience AzureADMultipleOrgs

Creating the app itself is not very useful for automation, but you can now find your app registration in Entra. This app registration can then be linked to service principals in 1 or more Entra Tenants.

The next step is to create a Service Principal, which can be done through the portal with the above link, or you can use the CLI by specifying the Object ID of the App Registration

az ad sp create --id e4448c00-e2f3-4227-a51c-87bd29aa39d9

If you refresh your app registration you can see it now has a managed application in local directory.

To find it in Entra you can navigate to the Enterprise Applications blade, then you will need to change the filter on the application type, to All Applications.

And it will now be finable in your directory.

 

Credentials

Now we understand what Service Principals are (both Managed Identities and App Registration based Service Principals), we need to be able to login as them.

This is done on the Managed Identity resource in Azure, or in the App Registration in Entra.

App registration Service Principal

Under the App registration, select the Certificates and secrets tab.

 

And here you can create the secrets. The best option here is Federated credentials as there are no secrets to handle. If you are using GitHub actions then this allows you to allow a GitHub actions workflow to log in as a service principal without secrets!

 

Managed Identity

As above, we can create a federated credential. For Managed Identity, there is no option to create a secret.

 

Trade Offs

Using User assigned Managed Identities have a lot of advantages, but they cannot be assigned API permissions, unlike App Registrations. The main advantage is they can be created in Azure using Azure permissions, rather than requiring the privileged role of Application Administrator or Application Developer.

This means that if you need your Service Principal to create and Manage an App Registration (for say a web application), then you will need to use a traditional Service Principal.

So the real decision point here is, use User Assigned Managed Identity if:

• You do not need to assign API Permissions (Graph etc)

• You will use Federated Credentials

Otherwise you should continue to use an App Registration based Managed Identity

Additional resources / references

Azure CLI - App Registration creation

App Registration defaults to AzureADMultipleOrgs - Application Registration created with "az ad sp create-for-rbac" defaults to global sign-in-audience · Issue #25881 · Azure/azure-cli