If you’re looking to automate and script processes and tasks against your Azure environment you’ll soon come across the issue of having to authenticate (which is good!) to your environment making your seamless automation script a little more manual.

The solution to this problem is to use a Service Principle (SP) with Role Based Access control (RBAC) to fine grain the permissions.

To create the Service Principle and App Registration on one step you can run the command:

az ad sp create-for-rbac –name “YOUR SP NAME”

However, it would be highly recommended to keep to the principle of least privilege and instead scope the SP to what you actually need – i.e. the resource group. You do this by specifying the –scope and additionally what role it needs to have, in my case ‘Contributor’:

az ad sp create-for-rbac –name “YOUR SP NAME –role contributor –scopes /subscriptions/{YOUR SUBSCRIPTION ID}/resourceGroups/{YOUR RESCOURCE GROUP NAME}

If you need to find the scope path you can use the resource browser – resources.azure.com

It is worth noting that if you specify the –password and a password you’ll receive a warning that the password argument will be removed in the near future (with CLI version 2.1.0) to address security concerns around known passwords. You can view the propeosed change here – https://github.com/Azure/azure-cli/issues/7538. If you Omit –password  you’ll allow the CLI to generate this for you. By default the password (secret) generated is valid for 1 year so you’ll need to make sure you keep a note of when it’ll expire.

Once you run the create command you’ll get a response of:

{

  “appId”: “YOUR APP ID”,

  “displayName”: “YOUR DISPLAY NAME”,

  “name”: “http://YOUR APP ID“,

  “tenant”: “this will be your tenant ID”

   “password”: “The password CLI generated for you”

}

Pulling it all together and testing it out. You can simply run the AZ Login to test the SP.

az login –service-principal -u {the appId} -p {the password} –tenant {your tenant ID}