blogs-image

Azure Service Principals vs Managed Identities: A Complete Guide for Secure Automation

Introduction

Identity and access management is a cornerstone of secure cloud automation in Azure. Two core concepts—Service Principals and Managed Identities—enable applications, scripts, and services to authenticate securely. But when should you use each? What are the security implications? This guide breaks down the differences, setup steps, usage examples, and best practices for both.

Purpose and Core Concepts

What is a Service Principal?

  • An identity created for use with applications, hosted services, and automated tools to access Azure resources.
  • Registered in Azure Active Directory (Azure AD).
  • Requires manual credential management (password or certificate).
  • Supports granular role-based access control (RBAC).

What is a Managed Identity?

  • An automatically managed identity for Azure resources to access other Azure services securely.
  • Eliminates the need for credentials in your code.
  • Two types: System-assigned and User-assigned.
  • Integrated with Azure AD and supports RBAC.

Feature Comparison

Feature Service Principal Managed Identity
Credential Management Manual (password/certificate) Automatic (no credentials exposed)
Scope Tenant-wide (can be used anywhere) Resource-scoped (bound to Azure resources)
Lifecycle Manual creation/deletion Automatic with resource lifecycle
Use Outside Azure Yes No (Azure only)
RBAC Support Yes Yes
Types Single System-assigned, User-assigned

Prerequisites

  • Azure subscription with sufficient permissions (Owner or Contributor).
  • Azure CLI or Azure PowerShell installed (for command-line steps).
  • Basic understanding of Azure Active Directory (Azure AD).

Step-by-Step Guide

Create a Service Principal
  1. Open your terminal and log in to Azure: 
    az login
  2. Create a new Service Principal: 
    az ad sp create-for-rbac --name "my-app-sp" --role contributor --scopes /subscriptions/<subscription-id>
  3. Note the appId, password, and tenant from the output. Store them securely.
  4. Use these credentials in your application or automation scripts.
Enable a Managed Identity
  1. Navigate to your Azure resource (e.g., Virtual Machine, App Service) in the Azure Portal.
  2. Go to the Identity blade.
  3. Switch the System-assigned identity to On and save.
  4. Assign the appropriate Azure role to the managed identity using the Access control (IAM) blade.
  5. Use the managed identity in your code to obtain tokens (no credentials needed).

Usage Examples

1. Azure CLI Authentication (Service Principal)

az login --service-principal -u <appId> -p <password> --tenant <tenantId>

2. Accessing Azure Key Vault (Managed Identity, C#)

var credential = new DefaultAzureCredential();
var client = new SecretClient(new Uri(keyVaultUrl), credential);
KeyVaultSecret secret = await client.GetSecretAsync("MySecret");

3. GitHub Actions with Service Principal

- name: Azure Login
  uses: azure/login@v1
  with:
    client-id: ${{ secrets.AZURE_CLIENT_ID }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    client-secret: ${{ secrets.AZURE_CLIENT_SECRET }}

4. REST API Call with Managed Identity (Bash)

ACCESS_TOKEN=$(curl -H "Metadata:true" \
  "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/" \
  | jq -r .access_token)
curl -H "Authorization: Bearer $ACCESS_TOKEN" https://management.azure.com/subscriptions?api-version=2020-01-01

5. Terraform Provider Authentication (Service Principal)

provider "azurerm" {
  features {}
  client_id       = var.client_id
  client_secret   = var.client_secret
  tenant_id       = var.tenant_id
  subscription_id = var.subscription_id
}

Security Best Practices

  • Prefer Managed Identities over Service Principals when possible to avoid credential exposure.
  • If using Service Principals, store secrets in secure vaults (e.g., Azure Key Vault).
  • Rotate Service Principal credentials regularly.
  • Assign only necessary permissions using RBAC.
  • Monitor sign-in activity and set up alerts for suspicious behavior.

FAQs

No, Managed Identities are only available for Azure resources. For external or on-premises scenarios, use Service Principals.

The system-assigned Managed Identity is automatically deleted along with the resource.

Yes, user-assigned Managed Identities can be shared across multiple Azure resources.

Credential rotation is handled automatically by Azure for Managed Identities. No manual action is required.

Use Service Principals for CI/CD pipelines running outside Azure. For pipelines hosted on Azure resources (e.g., Azure DevOps agents in Azure VMs), Managed Identities are recommended.

Further Reading