Exploring Workload Identities in Azure DevOps

Exploring Workload Identities in Azure DevOps

Workload identities in Azure DevOps allow applications, services, and automation tools to authenticate securely with Azure services or other resources. They integrate with Microsoft Entra ID (formerly Azure AD) to manage access using workload identities.

Microsoft Entra ID Workload Identities

1. Application:

   • Represents an application registered in Microsoft Entra ID.

   • Contains configuration metadata and can be associated with a service principal.

   • Example: An app registration for a custom-built application needing access to APIs or Azure services.

2. Service Principal:

   • A security identity for applications or services.

   • Represents an application or automation tool and allows it to authenticate.

   • Scoped permissions (using roles and policies) define what resources the service principal can access.

   • Example: A service principal for a CI/CD pipeline in Azure DevOps to deploy infrastructure.

3. Managed Identity:

   • A special type of service principal managed by Azure.

   • Provides identity to Azure resources like VMs or Azure Functions without requiring manual credential management.

   • Comes in two types:

     • System-assigned: Tied to a specific Azure resource and automatically deleted when the resource is deleted.

     • User-assigned: Created separately and can be associated with multiple resources.

Implementing Service Principals in Azure DevOps

Use Cases

1. Azure DevOps pipelines to access Azure resources (e.g., deploying infrastructure).

2. Automating Azure DevOps tasks with scripts or APIs.

3. Securely managing access to resources with granular permissions.

Implementation Steps

1. Register an Application in Microsoft Entra ID

   • Sign in to the Azure portal.

   • Navigate to Azure Active Directory →** App Registrations → New Registration**.

   • Provide a name for the app and configure its sign-in audience.

   • Click Register.

2. Create a Service Principal

   • After registering the application, a service principal is automatically created in the directory.

   • Go to Certificates & Secrets →** Client Secrets**.

   • Generate a new client secret and store the value securely (e.g., in Azure Key Vault).

3. Assign Permissions

   • Navigate to API Permissions in the app registration.

   • Add permissions required by the service (e.g., Azure Resource Management permissions for deployments).

   • Admin consent may be required for certain permissions.

4. Assign Roles to the Service Principal

   • Navigate to the Azure resource (e.g., subscription, resource group).

   • Go to Access Control (IAM) →** Add Role Assignment**.

   • Select the role (e.g., Contributor, Reader) and assign it to the service principal.

5. Configure Azure DevOps to Use the Service Principal

   • Navigate to Azure DevOps →** Project Settings → Service Connections**.

   • Click New Service Connection → Choose Azure Resource Manager.

   • Select the option to use a Service Principal (manual).

   • Enter the Client ID, Client Secret, and Tenant ID of the service principal.

Using the Service Principal in Azure Pipelines

Once configured, the service connection can be used in Azure DevOps pipelines.

Example YAML snippet:

xxxxxxxxxx
12
1
trigger:
2
- main
3
pool:
4
  vmImage: 'ubuntu-latest'
5
steps:
6
- task: AzureCLI@2
7
  inputs:
8
    azureSubscription: '<Service Connection Name>'
9
    scriptType: 'bash'
10
    scriptLocation: 'inlineScript'
11
    inlineScript: |
12
      az group list

Security Best Practices for Service Principals

Use Least Privilege:

1. Assign only the minimum necessary roles to the service principal.

2. Example: Use Contributor for resource management, not Owner.

Secure Client Secrets:

1. Store client secrets in Azure Key Vault or other secure locations.

2. Rotate secrets regularly.

Audit and Monitor:

1. Use Azure AD logs to monitor service principal activity.

2. Review permissions periodically to ensure compliance.

Use Managed Identities When Possible:

Prefer managed identities for Azure-hosted services to eliminate manual secret management.

Comparison of Workload Identities

Summary

By implementing and securing workload identities, Azure DevOps pipelines and applications can authenticate seamlessly while adhering to security best practices.