What is a service principal?
Azure has a notion of a Service Principal which, in simple terms, is a service account. On Windows and Linux, this is equivalent to a service account. These accounts are frequently used to run a specific scheduled task, web application pool or even SQL Server service. In a cloud context, Service Principals are the new paradigm. They are great because they allow you to provision an account that only has enough permissions and scope to run a task within a predefined set of Azure resource. It is vital that you don’t use your own account to run these tasks and it all boils down to the principle of "least privilege" and accountability. Throwaways accounts such as Service Principals with locked down permissions are easier to provision, monitor and de-provision if something goes wrong. You can define as many applications and service principals as you need, whereas normal accounts are limited by your Azure Subscription quotas. The most common use of Service Principals is for running automation tasks, runbooks and Continuous Deployment. And when we talk about CI/CD then Visual Studio Team Service has a great integration with Azure AD and Service Principals for release management.
How do I create a service principal?
Now that I've managed to convince you of the importance of Service Principals, we can go ahead and create one. Service Principals rely on a corresponding Azure Active Directory application. The permissions and scope are applied directly to the service principal. In this post I'll show you how to create a service principal using both PowerShell and the Azure CLI. Funnily enough these 2 tools are now both cross platform (albeit PoSH's still in beta) and you still have the option to do all this in the Azure portal.
Using PowerShell to create a Service Principal
Make sure you've downloaded the latest Azure PowerShell from the [Azure downloads page](https://azure.microsoft.com/en-us/downloads/" target="_blank). Open a new PowerShell window and run the following code once you change the parameters relevant to you.
Information on all available roles (RBAC) can be found [here](https://docs.microsoft.com/en-us/azure/active-directory/role-based-access-built-in-roles" target="_blank).
Using the Azure CLI to create a Service Principal
For this post I'll use the current version of the Azure CLI instead of the really cool [CLI 2.0](https://azure.microsoft.com/en-us/blog/announcing-azure-cli-2-preview/" target="_blank) (currently in Beta). I'll blog about the new CLI over the next couple of days. In the meantime, let's look how to create a Service Principal using the current CLI.
You can download and install the CLI either using Node's NPM package manager or through the native installers. My NPM installation failed on my Windows machine the first time, so I resorted using the native installer. On the Mac, the NPM installer worked fine the first time. You can read all about the available installers on the official [Azure CLI page](https://docs.microsoft.com/en-us/azure/xplat-cli-install" target="_blank)
sudo npm install -g azure-cli
With the tooling in place, we're good to start using the CLI to create our Service Principal:
The default RBAC role assigned to the Service Principal is Contributor. Although this is great because it's easy to work with, it's also extremely dangerous and against what we're really trying to achieve: per task/application permissions to a subset of resources. You can easily change the Service Principal roles by adding and removing the necessary roles (ideally custom ones) with the following commands:
az role assignment create --assignee <your Service Principal ID> --role <YourCustomRole> az role assignment delete --assignee <your Service Principal ID> --role Contributor az role assignment list --assignee <your Service Principal ID>
I hope this proved how easy it is to programmatically create a Service Principal to use in your application, tasks and CLI commands.