Getty Images/iStockphoto
Why and how to create Azure service principals
Service principals let cloud admins control access to Azure resources. Follow this step-by-step example to get started.
Some IT administrators use hardcoded passwords in automation scripts -- a move that can introduce security vulnerabilities. Within Azure, service principals eliminate this risk.
A service principal in Azure Active Directory (AD) is a form of security identity. Admins assign an Azure service principal to an object, such as an automated tool, application or VM. Then, they use role-based access controls to manage that object's access to Azure resources, rather than use security credentials within scripts.
Admins create a service principal in each tenant -- or dedicated Azure AD instance -- in which an application is used. A single-tenant application requires one service principal. A multi-tenant application requires a service principal in each tenant. To better understand service principals, we will walk through an example, as well as how it relates to managed identities.
Service principal example
As an example, an Azure service principal could be useful when an administrator wants to use Terraform to build or update an Azure cloud environment without having to provide credentials. If an admin were to read the Terraform script, there would be no username/password to intercept.
Step 1. To create and use a service principal, open the Azure portal. Then, open the BASH command-line interface (CLI). Enter the following command, substituting your own, more specific name for the service principal:
az ad sp create-for-rbac --name "ttexamplesp"
The command will take a few minutes to process. Notice the warning about role assignments in Figure 1.
This warning occurs because the service principal is assigned the Contributor role by default. This role grants permission for a service principal to read information, as well as write or change information and objects. To restrict these permissions, change the role to Reader, which grants read-only privileges. To assign the Reader role when creating a service principal, enter the following command:
az ad sp create-for-rbac --role reader --name "ttexamplesp"
Step 2. Use the credentials shown in Figure 1 within the application that supports them and asks for them. Securely note down these credentials, as they will not be shown again. By default, service principals have a lifespan of one year before the password expires. The password will only work with the service principal account. When a service principle needs to run a script, it will require the password in order to run.
Step 3. After downloading and installing the Azure CLI, use the following command to log in and test the service principal's credentials. Specify the app_id, password and tenant_id (shown in bold below):
az login --service-principal --username app_id --password password --tenant tenant_id
To see the current login status and verify the system is connected, use az account show, as shown in Figure 2.
Any issued command will run with the assigned credentials. For example, when admins assign the Reader role to a service principal, they grant read-only rights to the tenant. Admins can restrict these permissions to certain management groups or individual resources, such as VMs or load balancers.
Azure service principals vs. managed identities
Service principals are just one form of security identity in Azure -- another is managed identities. They provide an identity to applications that access Azure resources. Both service principles and managed identities enable fine-grained, programmatic access to Azure infrastructure without having to put passwords into scripts.
Managed identities can be system-assigned or user-assigned. With system-assigned managed identities, admins create the identity as a part of a specific Azure resource, such as a VM. That identity shares a lifecycle with its associated resource. Meaning, when admins delete the resource, they also delete the identity. User-assigned identities, on the other hand, are not tied to a specific resource. They have their own lifecycle and can be shared across resources.
The key difference between Azure service principals and managed identities is that, with the latter, admins do not have to manage credentials, including passwords.
To create a managed identity, go the Azure portal and navigate to the managed identity blade. Then, assign a role to the identity. Usefully, administrators can set the duration of validity for a managed identity.
