How to create and test Azure Service Principal using Azure CLI
Many automation tools (e.g. HashiCorp’s Packer.io and Terraform) and SDKs (e.g. Azure SDK for Java, Ruby, Python, Go, Node, etc.) that communicate with Azure using the Azure Resource Manager (ARM) APIs need a “Service Principal” credential for authentication via Azure Active Directory.
This credential is usually defined by specifying the following properties somewhere within the automation tool configuration or application code that uses the SDK:
In this article, I show how we can use Azure CLI with a client_secret assigned to an application (i.e. for sample purposes, I define my key as “VerySecureLongStringHereToRepresentTheSecretForTheApp”). I also demonstrate how to test my service principal using Azure CLI.
Finally, on the very bottom of this post, I include a link to another document that provides a similar run down.
Creating a service principal
This is usually a onetime activity that you can also perform in the portal. In this article, I am specifically showing how to do it from Azure CLI.
Login to your subscription from your own workstation using account that has permissions to add users and apps to the Azure AD
azure login azure account list azure account set "ArsenVlad MSDN Subscription"
Create an application which will be given the service principal
azure ad app create --name "MyBuildTestApp1" --home-page "http://localhost/MyBuildTestApp1" --password "VerySecureLongStringHereToRepresetTheSecretForTheApp" --identifier-uris http://localhost/MyBuildTestApp1
List service principals that are already in your Azure AD
There maybe many of these.
azure ad sp list
Create service principal for the application that you created above using its ApplicationId (AppId above)
azure ad sp create 485137ad-2401-41e7-b101-dc719bce4056
View Application and Add More Keys using the Portal (optional)
You can now see this application in the “old” manage.windowsazure.com portal that shows the Azure Active Directory
You can see the application’s client_id (which is the application id above) on the Configure tab. The secret key we generated above is listed as the “1 year” key in the list.
Using the portal UI, you also can easily add additional automatically generated random “keys” to the application you created.
To generate a new “key”, you would click on the drop-down in the keys-section, select the length of time (1 or 2 years) that the key will stay valid, and click “Save”.
After “Save” operation completes successfully, you will see the generated key and a warning “Copy and store the key value. You won’t be able to retrieve it after you leave this page.”
Assigning Role Based Access Control (RBAC)
Now, you will need to assign RBAC to the service principal so that it can perform ARM related actions within the subscription
You can assign permissions in the https://portal.azure.com or via Azure CLI. I am showing how to assign “Reader” role to the service principal (Object Id 03ba7016–53c4–456f-a38a-525d7a1938be) I created above. The “Reader” role will obviously not allow this SP to deploy resources, but you can assign your SP the proper role. I am just showing it using the Reader role to avoid mistakes :)
Show the definition of the role “Reader”
azure role show Reader
Create role assignment for the service principal (SP) that I created above at the scope of my subscription id
You can set this SP to only have Contributor/Reader/etc. permissions at the scope of your specific resource groups or resources instead.
azure role assignment create --objectId "03ba7016-53c4-456f-a38a-525d7a1938be" --roleName "Reader" --scope "/subscriptions/d2553556-6ac3-4241-87e8-a66deba80362"
Confirm that role assignment happened
azure role assignment list --objectId 03ba7016-53c4-456f-a38a-525d7a1938be
We can also see the role assignment in the https://portal.azure.com
Login using the Service Principal
Now that we have the service principal with its secret, we can login using Azure CLI and this service principal.
As mentioned in the introduction to this article, we need 3 pieces of information for the Azure Active Directory to grant us the proper access token:
- client_id: which is object id of the application we created above (485137ad-2401–41e7-b101-dc719bce4056)
- client_secret: this is the “password” we used when creating the service principal (it is not something that a person should remember it is a long string or “key” that portal creates when you create applications in the portal UI)
- tenant_id: the GUID representing the Azure Active Directory instance that the subscription is using and which will perform the authentication and will issue the access token
Let’s get the tenant id
azure account show "ArsenVlad MSDN Subscription"
Now, let’s actually try to login
azure login --service-principal --username "485137ad-2401-41e7-b101-dc719bce4056" --password "VerySecureLongStringHereToRepresetTheSecretForTheApp" --tenant "dd74924a-88ce-421a-ac87-00fc9dbe4baf"
Test the Service Principal RBAC
Now, let’s see if the login is restricted to the service principal with Reader role by trying to create a resource group to make sure it fails
azure group create westus mytestgroup
Check that reading (i.e. “Reader” role) does work properly
azure group list
If you want another run down of the ARM authentication requirements and steps to create the service principal, take a look at the this document for packer.io Azure ARM plugin.
In this article I focused specifically on authenticating via client_id and client_secret (i.e. “key” or “password”). If you want to learn about how to authenticate using an X509 certificate public key, take a look at my previous post Certificate-based auth with Azure Service Principals from Linux command line
I’m looking forward to your feedback and questions via Twitter https://twitter.com/ArsenVlad
Originally published at blogs.msdn.microsoft.com on May 11, 2016.