When I worked with on-prem IT infrastructure I was always keen to automate parts as much as possible, whether that was setting up a scheduled task to stop and start services on temperamental servers or automating the patching of the servers. One thing that was often essential to these automation tasks was a service account.
The service account was a bit like a user account with a username and password, and it often had access to local and network resources to perform these automation tasks. Using service accounts allowed us to avoid embedding our own network usernames and password into these automation tasks.
Within Azure when we want to automate tasks we have to use something similar, and it’s called a Service Principal. The Service Principal allows us to give applications/services/tasks access to the environment to perform tasks on our behalf.
When you create automation service accounts or Service Principals you should really think about what rights you give them. They shouldn’t have more permissions than they need. Only those that really need full administrator rights should have them! 😉
Create a Service Principal
Creating a Service Principal can be done in a number of ways, through the portal, with PowerShell or Azure CLI.
I have a small script that creates my Service Principal and it generates a random password to go with the Service Principal so that I have it for those password-based authentication occasions. When you create a Service Principal via PowerShell you do not get a copy of the password displayed, so you need to input a couple of lines of code to retrieve the password, as you can see in the code below.
# Create the Service Principal, generates a random password
$sp = New-AzADServicePrincipal -DisplayName ServicePrincipalName
# Export the random password that was generated on creation
$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($sp.Secret)
$UnsecureSecret = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)
$UnsecureSecret
The Azure CLI command to create a Service Principal is shorted and on creation the randomly generated password is displayed on screen.
az ad sp create-for-rbac --name ServicePrincipalDisplayName
Grant your Service Principal Rights
By default, when you a create a Service Principal via Azure CLI or PowerShell it grants it Contributor access to your Azure subscription. As I mentioned at the start of this post that isn’t great best practice. So, this is something to be aware of, when using Azure CLI.
My recommendation would be to remove the contributor role assignment and add the correct level. Where possible I try and restrict rights to resource group level and not directly at the subscription level.
Of course, there are times when you need to grant Contributor level to your Service Principals at the subscription level for certain tasks.
Sign in with a Service Principal
Now that you have your Service Principal and permissions assigned, how do you use them? Signing into via PowerShell or Azure CLI can be quite quickly achieved.
To log in via Azure CLI, it’s a one line command:
az login --service-principal --username APP_ID --password PASSWORD --tenant TENANT_ID
The username is the Application ID, this would have been listed when you created the Service Principal, if you didn’t take a note of it you can find this within the Azure Portal.
The password would have also been listed when you created the Service Principal.
The tenant ID would also have been listed, if you don’t have a note of it you can run the command to get a note of it.
azure account show
To log in via PowerShell it is slightly more complex and requires a bit more code. The first command to issue is one that gathers the password for the Service Principal:
$passwd = ConvertTo-SecureString “SECURE PASSWORD” -AsPlainText -Force
The next command takes the Service Principal ID and password and combines them into one variable:
$pscredential = New-Object System.Management.Automation.PSCredential('SERVICE PRINCIPAL NAME or ID', $passwd)
The last command takes the inputted information and logs you in:
Connect-AzAccount -ServicePrincipal -Credential $pscredential -Tenant TENANT_ID
Things to remember
Make sure that you use good password storage practices when automating service principal connections. I’ve shown you code that displays the passwords in plain text, which isn’t best practice but gives you an idea of how to use the commands and Service Principal concept. Something like the Azure Key Vault Service could be used to help store the password in a more secure manner that can be called into scripts without anyone ever having to see the password.
For security purposes, Service Principal passwords are created with a default lifespan of a year, so don’t forget to make a note in your diary to renew the credentials or you may hit errors!
Microsoft
