Edit

Using a service principal to authenticate

  • Article

Sometimes it's unsuitable to use interactive authentication or to authenticate as a user account. These cases may arise when you want to submit jobs from a web service, another worker role, or an automated system. One option is to configure a managed identity, another option is to use a Service Principal, which this article will explain.

Prerequisite: Create a service principal and application secret

To authenticate as a service principal, you must first create a service principal.

To create a service principal, assign access, and generate a credential:

  1. Create an Azure AD application:

    Note

    You do not need to set a redirect URI.

    1. Once created, write down the Application (client) ID and the Directory (tenant) ID.

  2. Create a credential to sign in as the application:

    1. In the settings for your application, select Certificates & secrets.
    2. Under Client Secrets, select Create New Secret.
    3. Provide a description and duration, then select Add.
    4. Copy the value of the secret to a safe place immediately - you won't be able to see it again!

  3. Give your service principal permissions to access your workspace:

    1. Open the Azure portal.
    2. In the search bar, enter the name of the resource group you created your workspace in. Select the resource group when it comes up in the results.
    3. On the resource group overview, select Access control (IAM).
    4. Select Add Role Assignment.
    5. Search for and select the service principal.
    6. Assign either the Contributor or Owner role.

Note

In order to create a role assignment on the resource group or workspace, you need to be an owner or user access administrator at the scope of the role assignment. If you do not have permissions to create the Service Principal in your subscription, you will need to request permission from the owner or administrator of the Azure subscription.

If you have permissions only at the resource group or workspace level, you can to create the service principal under the Contributor role using:

az ad sp create-for-rbac --role Contributor --scopes /subscriptions/<SUBSCRIPTION-ID>

Authenticate as the service principal

Option 1: Using environment variables: The default credential used in the Workspace object creation is the DefaultAzureCredential, which will attempt several types of authentication. The first one is the EnvironmentCredential, and with that you pass the Service Principal credentials via the following environment variables:

  • AZURE_TENANT_ID: ID of the service principal’s tenant. Also called its ‘directory’ ID.
  • AZURE_CLIENT_ID: the service principal’s client ID.
  • AZURE_CLIENT_SECRET: one of the service principal’s client secrets.

Option 2: Using the ClientSecretCredential: Pass a ClientSecretCredential during the instantiation of the Workspace object or set the credentials property.

from azure.identity import ClientSecretCredential

tenant_id = os.environ["AZURE_TENANT_ID"]
client_id = os.environ["AZURE_CLIENT_ID"]
client_secret = os.environ["AZURE_CLIENT_SECRET"]
credential = ClientSecretCredential(tenant_id=tenant_id, client_id=client_id, client_secret=client_secret)

workspace.credentials = credential

Note

The workspace.login() method has been deprecated and is no longer necessary. The first time there is a call to the service, an authentication will be attempted using the credentials passed in the Workspace constructor or its credentials property. If no credentials were passed, several authentication methods will be attempted by the DefaultAzureCredential.