Azure  

Azure Service Principle Simplified

When I first encountered the term “Service Principal”, I was completely confused.

Was it a user? Was it an app? Was it a login account?

And why did it need its own password or secret key?

If you’re getting started with cloud infrastructure, especially in Azure, the concept of a Service Principal can feel vague and overly abstract.

You’re not alone many professionals, especially those coming from traditional development or sysadmin backgrounds, struggle to understand.

What exactly is a Service Principal?

When and why should you use one?

In this post, I’ll break it down in plain language, using real-world example and code snippets— so by the end, you’ll never be confused by the term again.

Service Principal is like a user account for apps or services that need to access Azure resources. For example in order to log in to the system user needs a name and password, similarly is a kind of username and password for the app to access resources in Azure.

Azure

Very Simple Definition

A service principal is a special account that lets an app or automation tool sign in to Azure and do things, like start a virtual machine or deploy code — but only what you allow it to do.

It’s not a person, but it has its own ID and password (called a client ID and secret), and you can control what it’s allowed to access using roles and permissions.

Scenarios

1. When You Register an Application in Azure AD

  1. Scenario: You create an app registration (e.g., for a web app, API, or daemon service).
  2. Result: Azure automatically creates a corresponding Service Principal in your tenant.
  3. Purpose: The app can then authenticate and access resources based on the permissions you assign to the service principal.
    • App Registration: Identity
    • Service Principal: Role-playing identity inside a tenant

2. When You Create an Azure Resource That Needs to Access Other Resources

Examples

  • Azure Kubernetes Service (AKS)
  • Azure App Service with managed identity
  • Azure Data Factory with linked services
  • Result: Azure automatically creates a Managed Identity, which is essentially a Service Principal under the hood.

System-assigned managed identity is tightly coupled with the resource and gets deleted if the resource is deleted.

3. When Using Azure DevOps Service Connections

  • Scenario: You create a Service Connection in Azure DevOps to deploy resources to Azure.
  • Result: Azure DevOps automatically creates a service principal and assigns it the required permissions (e.g., Contributor role).

It’s best practice to regularly audit these service principals and rotate secrets if not using the managed identity.

Create a Service Principal with permissions to access a specific Azure subscription or resource group.

bash

az ad sp create-for-rbac — name “terraform-deployer” — role=”Contributor” — scopes=”/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>”

This command outputs:json

CopyEdit

{
  "appId": "xxxxx-xxxx-xxxx-xxxx",
  "displayName": "terraform-deployer",
  "password": "xxxxxxx",
  "tenant": "xxxxx-xxxxx"
}

These credentials are saved as secrets in your CI/CD pipeline.

4. Configure Terraform with the Service Principal.

In your pipeline or terminal, set these environment variables.

  • bash
  • CopyEdit
export ARM_CLIENT_ID=xxxxx-xxxx
export ARM_CLIENT_SECRET=xxxxxxx
export ARM_SUBSCRIPTION_ID=xxxxx-xxxx
export ARM_TENANT_ID=xxxxx-xxxx

Now, Terraform can authenticate to Azure securely and automatically using the Service Principal.

Summary

Using a Service Principal (either directly or via Managed Identity) is a secure and scalable way to let your Azure applications access other Azure resources like Key Vault, Storage, or SQL without using hardcoded credentials. This approach enhances security, supports automation, and aligns with DevSecOps best practices.

Membership not found