Azure Pipelines - Sprint 246 Update
Features
- Ubuntu 24.04 on Azure Pipelines hosted agents
- Use Workload identity federation in Azure integration tests
- New Azure service connection creation experience with improved Managed identity support
- Run children stages when parent stage fails
Ubuntu 24.04 on Azure Pipelines hosted agents
The Ubuntu 24.04 image is now available for Azure Pipelines hosted agents. To use this image, update your YAML file to include vmImage:'ubuntu-24.04':
- job: ubuntu2404
pool:
vmImage: 'ubuntu-24.04'
steps:
- bash: |
echo Hello from Ubuntu 24.04
lsb_release -d
Note
The ubuntu-latest image label will continue to point to ubuntu-22.04 until later this year.
See the Ubuntu 24.04 image readme for installed software.
Use Workload identity federation in Azure integration tests
In June, the Azure Identity libraries for.NET, C++, Go, Java, JavaScript, and Python added support for workload identity federation. This added the ability for code executed from the AzureCLI@2 and AzurePowerShell@5 tasks to authenticate with Microsoft Entra (for example, to access Azure) with the AzurePipelinesCredential class.
Many customers are using the Azure Identity libraries in integration tests invoked from other tasks. We've now added support for AzurePipelinesCredential to the DotNetCoreCLI@2, Maven@4 and VSTest@3 tasks.
You can set the connectedService property to an Azure service connection configured with workload identity federation. The AzurePipelinesCredential requires SYSTEM_ACCESSTOKEN to be set.
- task: DotNetCoreCLI@2
inputs:
command: 'run'
connectedService: <Azure service connection configured with workload identity federation>
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
For more information on AzurePipelinesCredential, see this blog post.
New Azure service connection creation experience with improved Managed identity support
The new Azure service connection creation experience provides increased flexibility and secure defaults. It also aligns terminology with Microsoft Entra ID, so that users who create Microsoft Entra ID objects manually have a better understanding when navigating different portals.
When creating a new Azure Resource Manager service connection, the various options to configure identity are now available in a single unified dialog that replaces the distinct top level items used previously:
Identity type lists all authentication schemes the Azure service connection supports:
For app registrations, you can independently select Credential to be workload identity federation or a secret.
Azure Service Connection Managed Identity support
You can now select a pre-existing managed identity and use it to configure a service connection that uses workload identity federation. First, create a User-assigned Managed Identity.
Then, create an Azure service connection and select the Managed identity Identity Type. This configures federated identity credentials on the managed identity.
The option to use a managed identity assigned to an agent (pool) has been renamed Managed identity (agent-assigned). To prevent sharing over-privileged managed identities, it's recommended to use a managed identity with workload identity federation instead of managed identities assigned to agent pools.
Managed identity is also the recommended option for users who can't create an App registration if that is disabled in Microsoft Entra ID.
To use a managed identity with workload identity federation, first select the subscription and resource group that holds your managed identity. This can be different from the subscription the service connection accesses in pipeline jobs. Pick the managed identity that is configured for workload identity federation. The user needs the Managed Identity Contributor role or equivalent permissions on the managed identity to create federated identity credentials on it.
Continue to select the subscription that will be used as the deployment scope for the service connection.
Service Management Reference field
Some organizations require the Service Management Reference of an App registration to be populated with relevant context information from an ITSM database. If necessary to do so, users can specify this reference at service connection creation time.
More information
The new Azure service connection creation experience is rolling out over the next month. For more information, see:
Run children stages when parent stage fails
We made it easier to continue deployments using Azure Pipelines. This is useful, for example, when you use Pipelines to deploy new versions of your application across multiple Azure regions.
Say you need to deploy to five consecutive Azure regions. Assume your pipeline has a stage for each region, and each stage has a job that runs an AzureResourceManagerTemplateDeployment task, and then it logs some telemetry. The latter is nice to have, but not critical. Imagine there's an issue logging the telemetry. Now, the stage fails and the deployment stops.
Starting with this sprint, when a stage fails, you can resume running its children stages.
Next steps
Note
These features will roll out over the next two to three weeks.
Head over to Azure DevOps and take a look.
How to provide feedback
We would love to hear what you think about these features. Use the help menu to report a problem or provide a suggestion.
You can also get advice and your questions answered by the community on Stack Overflow.