Microsoft Entra ID Service Accounts (formerly known as Azure Active Directory Service Accounts) are specialized accounts created to provide non-human identities with access to Azure resources. These accounts are essential for running applications, scripts, and services that need to interact with Azure resources securely, without tying access to a specific user.
Service accounts in Entra ID serve as “identity proxies” for applications or automated processes, allowing secure access to resources without the risks associated with using human credentials.
Types of Service Accounts in Microsoft Entra ID
In Microsoft Entra ID, there are different types of service accounts, each serving specific use cases and security requirements:
- Application Registration and Service Principal (SPN) Accounts: Service accounts created for applications to authenticate and access resources.
- Managed Identities: Special service identities that Azure automatically manages, commonly used by Azure services like Virtual Machines, Azure Functions, and Logic Apps.
Overview of Each Type
| Service Account Type | Description | Use Cases |
|---|---|---|
| Service Principal (SPN) | Represents an application or service in Entra ID | Custom applications, third-party apps, and automations |
| Managed Identities | Azure-managed identities for secure access to resources | Azure VMs, Functions, Logic Apps accessing other Azure services |
1. Service Principal (SPN)
What is a Service Principal (SPN)?
A Service Principal (SPN) is an identity created to represent an application or service in Microsoft Entra ID. It provides the application or service with an “identity” that it can use to authenticate to Azure resources. Service Principals are part of Azure’s Application Registration model and are essential for controlling access and permissions for non-human identities.
Key Features
- Secure Access: Service Principals provide secure, non-human identities for applications, protecting Azure resources from unauthorized access.
- Granular Permissions: SPNs are assigned roles based on the principle of least privilege, ensuring they only have access to necessary resources.
- Credential Management: SPNs can authenticate using certificates, secrets, or federated identity credentials, and these credentials can be securely stored and managed in Azure Key Vault.
Usage Scenarios
- Automating Deployments: Service Principals are often used by CI/CD pipelines, such as GitHub Actions or Azure DevOps, to deploy code to Azure resources securely.
- Accessing Resources for Custom Applications: When building custom applications that need to interact with Azure resources (like databases or storage accounts), a Service Principal can be created to authenticate securely.
- Integrating Third-Party Applications: Third-party applications, like monitoring tools or security solutions, often require a Service Principal to connect to and retrieve data from Azure.
Working Example of a Service Principal (SPN)
Scenario: Automating a Web App Deployment using GitHub Actions
A company is building a web application in Azure and wants to automate its deployment process using GitHub Actions. To do this, they need a secure way for GitHub Actions to authenticate and deploy resources to Azure.
- Create a Service Principal:
- In the Azure Portal, navigate to Microsoft Entra ID > App registrations > + New registration.
- Register an application for the deployment automation, such as “WebApp Deployment Service Account.”
- Assign Roles and Permissions:
- Under Certificates & Secrets, create a client secret (a password) or upload a certificate to use for authentication.
- Go to Azure subscriptions or Resource Groups and assign the Service Principal the required permissions (e.g., Contributor role) to deploy resources.
- Configure GitHub Actions:
- Add the Service Principal’s client ID, tenant ID, and client secret as environment variables in GitHub.
- In the GitHub Actions workflow, use these credentials to authenticate and deploy resources to Azure.
Result: GitHub Actions uses the Service Principal to authenticate and deploy resources to Azure without requiring human intervention or credentials, ensuring secure automation.
2. Managed Identities
What is a Managed Identity?
Managed Identities are special types of service identities that Azure automatically manages. Managed Identities are designed to simplify the process of granting applications (hosted on Azure services) access to Azure resources without requiring credentials. Managed Identities come in two types:
- System-Assigned Managed Identity: Created and associated directly with a single Azure resource, such as a Virtual Machine, Azure Function, or Logic App. When the resource is deleted, the identity is also deleted.
- User-Assigned Managed Identity: Created as a standalone identity that can be assigned to multiple Azure resources. User-assigned managed identities persist even if the associated resources are deleted.
Key Features
- No Credential Management: Azure automatically creates, manages, and rotates the credentials for Managed Identities, reducing the risk of credential leaks.
- Built-In Integration: Managed Identities work seamlessly with Azure services like Azure Key Vault, Azure SQL Database, and Azure Storage, allowing secure resource access without manually configuring credentials.
- RBAC Support: Managed Identities can be assigned specific roles in Azure RBAC, allowing them to access resources according to the principle of least privilege.
Usage Scenarios
- Secure Access for Azure VMs: A Virtual Machine running applications that need to access Azure Storage or Azure SQL Database can use a managed identity for secure access without credentials.
- Serverless Applications: Serverless functions and workflows in Azure Functions, Logic Apps, or App Services can use managed identities to securely access secrets in Azure Key Vault or data in Azure Storage.
- Multi-Resource Access: With User-Assigned Managed Identities, multiple resources like VMs, Azure Functions, and App Services can share a single identity for accessing shared resources.
Working Example of Managed Identities
Scenario 1: System-Assigned Managed Identity for a Virtual Machine Accessing Azure Key Vault
A development team has a Virtual Machine (VM) running in Azure that needs to retrieve secrets, such as database connection strings, from Azure Key Vault.
- Enable Managed Identity on the VM:
- In the Azure Portal, go to the VM’s settings and enable the System-Assigned Managed Identity under Identity.
- Grant Access to Azure Key Vault:
- In the Azure Key Vault, go to Access Policies and assign the managed identity of the VM with “Get” permissions to access secrets.
- Retrieve Secrets Securely:
- The application running on the VM can now use the Managed Identity to authenticate to Azure Key Vault and retrieve secrets without needing hardcoded credentials.
Result: The VM securely accesses secrets in Azure Key Vault without any password or client secret, minimizing the risk of credential exposure.
Scenario 2: User-Assigned Managed Identity for Multiple Azure Functions Accessing a Shared Database
An organization has multiple Azure Functions that need to access a shared Azure SQL Database. To avoid creating separate identities for each function, the organization uses a User-Assigned Managed Identity.
- Create a User-Assigned Managed Identity:
- In the Azure Portal, go to Microsoft Entra ID > Managed Identities and create a new User-Assigned Managed Identity.
- Assign the Identity to Azure Functions:
- For each Azure Function that needs access, go to the function’s Identity settings and assign the User-Assigned Managed Identity.
- Grant Database Permissions:
- In the Azure SQL Database, assign the Managed Identity with the appropriate database permissions (e.g.,
db_datareader,db_datawriter).
- Access the Database:
- Each Azure Function can now authenticate to the Azure SQL Database using the Managed Identity, eliminating the need for passwords or stored credentials.
Result: All Azure Functions securely access the database using a shared User-Assigned Managed Identity, simplifying management and improving security.
Summary of Service Accounts in Microsoft Entra ID
| Service Account Type | Description | Use Cases | Working Example |
|---|---|---|---|
| Service Principal (SPN) | Identity representing an application or service | CI/CD pipelines, third-party apps, automation | GitHub Actions deploys to Azure with an SPN |
| System-Assigned Managed Identity | Identity tied to a specific Azure resource (auto-created and deleted with resource) | Access resources from VMs, Azure Functions | VM accesses Key Vault with managed identity |
| User-Assigned Managed Identity | Independent identity assigned to multiple Azure resources | Shared identity for multi-resource access (e.g., multiple functions accessing a single database) | Multiple Azure Functions access a shared SQL Database |
Choosing the Right Service Account Type
- Use Service Principals (SPN) for applications, automations, or third-party tools that need to authenticate to Azure but are not directly hosted on Azure.
- Use System-Assigned Managed Identities for resources like Virtual Machines, Azure Functions, or Logic Apps that require secure access to Azure resources, and where the identity can be deleted with the resource.
- Use User-Assigned Managed Identities when you need a single identity that can be assigned to multiple Azure resources, or when you need an identity to persist independently of the resource lifecycle.
Security Best Practices for Using Service Accounts in Microsoft Entra ID
- Apply the Principle of Least Privilege: Only assign the minimum permissions necessary for the service account to function.
- Rotate Credentials for Service Principals: For service principals using client secrets, ensure regular rotation of credentials to maintain security.
- Use Managed Identities for Azure Services: Whenever possible, use Managed Identities instead of client secrets
, as Azure automatically manages the credentials.
- Monitor Access and Usage: Regularly audit access logs and activity for service accounts to detect any unusual or unauthorized access.
By leveraging Microsoft Entra ID Service Accounts effectively, organizations can securely and efficiently manage non-human identities in Azure, enabling secure application automation, service integration, and inter-service communication.
