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:

image

image

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.

I include a few screenshots of the Azure management portals (current/new – portal.azure.com and classic/old – manage.windowsazure.com) showing analogous information.

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

clip_image002

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

clip_image002[14]

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

clip_image00210

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.

clip_image00212

Using the portal UI, you also can easily add additional automatically generated random “keys” to the application you created.

image

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”.clip_image002[3]

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.”

clip_image002[5]

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 Smile

Show the definition of the role “Reader”

azure role show Reader

clip_image002[16]

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"

clip_image002[18]

Confirm that role assignment happened

azure role assignment list --objectId 03ba7016-53c4-456f-a38a-525d7a1938be

clip_image002[20]

We can also see the role assignment in the https://portal.azure.com

image

image

image

 

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:

  1. client_id: which is object id of the application we created above (485137ad-2401-41e7-b101-dc719bce4056)
  2. 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)
  3. 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"

clip_image002[22]

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

clip_image002[24]

Check that reading (i.e. “Reader” role) does work properly

azure group list 

clip_image002[26]

 

Conclusion

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.

Also, on Twitter, @StuartPreston mentioned his open source (Ruby) tool for automating the creation of the application, service principal, and role assignment for use with Chef, Puppet, and Terraform.

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

Comments (0)

Skip to main content