Authenticating to Azure

Terraform does not manage Azure resources directly; it talks to the Azure Resource Manager (ARM) API to create, update, and delete resources. Every call to ARM must be authenticated (who is making the request) and authorized (what the identity is allowed to do). Azure validates identities using Microsoft Entra ID and issues access tokens that Terraform’s Azure Provider uses for each API call. Terraform supports multiple authentication methods because it can run in different environments. All methods ultimately use Microsoft Entra ID, but the way credentials or tokens are acquired differs:

Azure CLI (best for local development)
Service Principal (typical for CI/CD automation)
Managed Identity (recommended for workloads running inside Azure)

Below we walk through each authentication method with example commands and recommended practices.

The image outlines three ways of authenticating to Azure: using Azure CLI, using Service Principal, and using managed identity.

How authentication works (quick overview)

Terraform requests an access token from Microsoft Entra ID.
The Provider includes that token in API calls to ARM.
ARM validates the token and enforces RBAC permissions assigned to that identity.

Choose an authentication method based on where Terraform runs:

Local machine or laptop → Azure CLI
CI/CD pipelines → Service principal
Azure-hosted VMs, App Services, or other resources → Managed identity

Quick comparison

Method	Best for	Credentials stored where	Typical setup
Azure CLI	Local development & demos	Local Azure CLI token cache	`az login`
Service Principal	CI/CD and automation	Client secret / certificate	`az ad sp create-for-rbac` + environment variables
Managed Identity	Azure-hosted workloads	No customer-managed secrets	Assign identity and RBAC to the Azure resource

The Azure CLI authenticates a user via Microsoft Entra ID and caches an access token locally. The Terraform Azure Provider detects the cached session and reuses the token for ARM API calls. The permissions used by Terraform are the role assignments of the signed-in user. Example: authenticate locally

az login

Use az login for interactive development, learning, and demos. Avoid using it for production automation because it uses your user identity, which may have broader permissions than necessary.

Notes:

If you use multiple subscriptions, set the active subscription with az account set -s <SUBSCRIPTION_ID>.
For headless CI scenarios, prefer a service principal instead of az login.

2) Service Principal

A service principal is an application identity in Microsoft Entra ID and is commonly used for automation and CI/CD. It provides a dedicated identity with scoped RBAC permissions. Create a service principal and assign it an RBAC role scoped to a subscription or resource group:

az ad sp create-for-rbac \
  --name tf-kodekloud \
  --role Contributor \
  --scopes "/subscriptions/d1e69bd8-2fe1-42bc-a3a7-ca4469cb5167/resourceGroups/echovisa-rg-7u9uby"

The command prints credentials (example output, sanitized):

{
  "appId": "5eaaf6c4-d542-4eb6-bd8d-24c0e5986f90",
  "displayName": "tf-kodekloud",
  "password": "REDACTED_SECRET",
  "tenant": "a8dab4a7-9027-461c-97ab-b022f15917a4"
}

Set environment variables so the Terraform Provider can authenticate:

export ARM_SUBSCRIPTION_ID="d1e69bd8-2fe1-42bc-a3a7-ca4469cb5167"
export ARM_TENANT_ID="a8dab4a7-9027-461c-97ab-b022f15917a4"
export ARM_CLIENT_ID="5eaaf6c4-d542-4eb6-bd8d-24c0e5986f90"
export ARM_CLIENT_SECRET="REDACTED_SECRET"

Do not commit service principal credentials to source control. Store secrets securely (for example, in Azure Key Vault) and rotate them regularly.

Why use service principals:

Suitable for non-interactive automation.
Allows least-privilege RBAC scoping to limit Terraform actions.
Can use client secret or certificate-based authentication.

Terraform will use these environment variables to acquire tokens from Microsoft Entra ID and call ARM on your behalf.

3) Managed Identity

Managed identities (formerly MSI) are Azure-managed service principals attached to an Azure resource (for example, a VM, Virtual Machine Scale Set, App Service, or Azure Function). They provide a secretless way for Azure resources to authenticate to Azure services. To use a managed identity with Terraform:

Enable a system-assigned or user-assigned managed identity on your Azure resource.
Assign the managed identity the necessary RBAC role at the appropriate scope.
Configure Terraform (or the environment) so the Azure Provider uses the managed identity. Example environment variables:

export ARM_USE_MSI=true
export ARM_SUBSCRIPTION_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
export ARM_TENANT_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

How it works:

The Azure resource requests tokens from the Instance Metadata Service (IMDS).
No client secrets are stored or shared.
Terraform running on that resource will acquire tokens transparently.

Managed identities are the recommended approach for Terraform running inside Azure because they remove credential management and reduce risk.

Best practices

Principle of least privilege: scope RBAC roles to the minimal required scope (resource group, resource, or custom roles).
Avoid embedding secrets in source control. Use secret stores like Azure Key Vault.
Prefer Managed Identity for Azure-hosted automation. Use service principals for external CI/CD systems.
For local development use az login, but ensure CI/CD uses explicit, auditable identities (service principals or managed identities).

Links and references

Microsoft Entra ID (Azure AD): https://learn.microsoft.com/azure/active-directory/
Azure Resource Manager (ARM): https://learn.microsoft.com/azure/azure-resource-manager/
Azure CLI: https://learn.microsoft.com/cli/azure/
Managed identities for Azure resources: https://learn.microsoft.com/azure/active-directory/managed-identities-azure-resources/
Create a service principal with Azure CLI: https://learn.microsoft.com/cli/azure/ad/sp#create-for-rbac

Summary:

Azure CLI (az login) is convenient for local work.
Service principals are ideal for CI/CD automation; secure secrets properly.
Managed identities are the recommended, secretless option for resources running inside Azure.

With these patterns you can authenticate Terraform to Azure in a secure and auditable way.

Introduction

Infrastructure as Code Fundamentals

Terraform Cloud

Setting up environment

Azure Context for Terraform

HashiCorp Configuration Language

Terraform Providers

Variables

Outputs and Dependencies

Iteration and Logic

Advanced Constructs

Terraform State Fundamentals

Remote State

Terraform Workspaces

Terraform CLI

Lifecycle Meta-Arguments

Data Sources

Provisioners

Debugging Terraform

Terraform Modules

Azure DevOps Integration

Azure Pipelines for Terraform

Authenticating to Azure

How authentication works (quick overview)

Quick comparison

2) Service Principal

3) Managed Identity

Best practices

Links and references

Watch Video

Practice Lab

​How authentication works (quick overview)

​Quick comparison

​1) Azure CLI (az login)

​2) Service Principal

​3) Managed Identity

​Best practices

​Links and references

Watch Video

Practice Lab

How authentication works (quick overview)

Quick comparison

1) Azure CLI (az login)

2) Service Principal

3) Managed Identity

Best practices

Links and references