Arin's Tech Musings

In Part 1  we had covered the topics of understanding Azure Service Principals and how to create them. In this part we will look at using the Service Principals in a secure manner when creating Azure Automation Runbooks and carrying out AzureRM tasks. We will not get into the details of how to create a automation account in Azure. It is very simple to follow the Microsoft Docs  to create an automation account and also learn how to create a runbook and schedule it. We will now focus on the how-to of using an Azure Service Principal in our PowerShell script. In this example we will use the Password-based Service Principal for simplicity. Maybe I'll create another post for the certificate based service principal in a later update. Note: The Service Principal can be used as any other account in Azure. So, you can use it with RBAC across Resource Groups/Resources as might be necessary. Go to your Automation Account resource and scroll down to find "Credentials" in t

So you need to run a PowerShell script inside a Azure Automation account and the script uses AzureRM cmdlets. How would you authenticate? Do you use a user account? But the user account could have more permissions than what is actually required for your script, opening a whole discussion around security. I have also seen organizations create user accounts that are used as service accounts. But what does Microsoft say? "Automated tools that use Azure services should always have restricted permissions. Instead of having applications sign in as a fully privileged user, Azure offers service principals. " So what is an Azure Service Principal? An Azure service principal is an identity created for use with applications, hosted services, and automated tools to access Azure resources. This access is restricted by the roles assigned to the service principal, giving you control over which resources can be accessed and at which level.  Service Principals offer 2 kinds o