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! ;)

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.

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.

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!