General availability of Workload identity federation for Azure Resource Manager service connections

  • Article

We’re excited to announce that Workload identity federation is now generally available in Azure Pipelines! You can enjoy a streamlined experience without the need to manage secrets and certificates in Azure service connections.

With this update, we are also previewing a new feature as part of our enhanced GitHub integration with Azure Boards. You can now link directly to GitHub pull requests or commits. No more switching between windows or copy/pasting. Simply select the repository you want, find the pull request or commit you need, and link it!

Check out the release notes to learn more about these features.

General

GitHub Advanced Security for Azure DevOps

Azure Boards

Azure Pipelines

Azure Repos

Azure Artifacts

General

Final notice of alternate credentials deprecation

Alternate credentials were formally deprecated in March 2020, but some existing users were grandfathered in with ongoing usage of their existing alternate credentials. As of January 2024 we've fully deprecating all alternate credentials.To avoid any potential disruptions, switch to one of the available authentication mechanisms we provide, such as personal access tokens or managed identities.

Azure Devops OAuth self-service secret rotation

Every five years, it's essential to update the Client Secret for your Azure DevOps OAuth app, to ensure continuous generation of access and refresh tokens necessary for utilizing Azure DevOps APIs. As your Client Secret approaches expiration, you can now independently generate a new one, providing your team the freedom to manage it without relying on customer support. This flexibility in scheduling secret rotation minimizes potential outage time for your customers waiting for a replacement due to an expired secret.

Screenshot of Select a geography.

Look for this new functionality in each of your Azure DevOps app pages that can be accessible through your profile here. Learn more about this new step in our Azure DevOps OAuth guide.

GitHub Advanced Security for Azure DevOps

Code snippets now available in alert details view

The alert detail page for code scanning and secret scanning alerts now shows code snippets that mark the one or more lines of code where the alert occurred. To go to the original file in your Azure DevOps repository, click on the file name above the code snippet.

Screenshot of case-sensitive middleware path.

Truncated secrets displayed in alert overview

The truncated, last six characters of any detected secrets are now displayed in the secrets alert overview screen. This feature is helpful if you have multiple secret exposures of the same secret type, allowing you to quickly identify where particular secrets live.

Screenshot of secret alerts list.

More alert severities added for code scanning alerts

New alert severities now exist for alert results from the CodeQL quality queries as Error, Warning, and Note severities. Each quality alert severity has its own badge and color to denote scaling severities. You can also filter for each of these severities, similar to the low to critical severity scale for security alerts.

Screenshot of code scanning alerts list and severity filter.

Linked Azure subscription required for GitHub Advanced Security for Azure DevOps enablement

If you previously enabled Advanced Security for repositories in an Azure DevOps organization without a linked Azure subscription, you may notice Advanced Security automatically disabled itself on those repositories. To re-enable Advanced Security, add an associated Azure subscription to the organization. For more information on how to add or change your subscription, see Change Azure subscription.

Advanced Security API updates

Various updates to the Advanced Security APIs recently shipped:

  • The GET Alerts API now supports a new parameter, ModifiedSince, to return an incremental list of alerts and only return alerts that were modified since this date. For more information, see Alerts - List.
  • There are two new endpoints to fetch or update an organization or project's Advanced Security enablement status. Both endpoints return a list of repositories with Advanced Security enabled. For more information, see Org - Enablement or Project - Enablement.
  • There are two new endpoints to fetch an estimate of your active committer count for an organization or project to reflect what your estimated Advanced Security meter usage may cost. For more information, see Org Meter Usage Estimate or Project Meter Usage Estimate.

Advanced Security permissions are now permanently displayed

In the past, the three Advanced Security permission bits would only be present as per-repository assignable permissions if Advanced Security was enabled. Now, these permissions are available by default at the Repositories > Security permissions pane and can be assigned without having Advanced Security to be enabled.

Screenshot of Advanced Security permissions.

Azure Boards

You have two options to connect your work item with a GitHub pull request or commit. You can either use the AB# syntax in the pull request, or you can link it directly from the work item. Today, the process involves copying the URL of the GitHub pull request and pasting it when adding a link. This requires opening multiple windows and switching between GitHub and Azure DevOps.

In this sprint, we're excited to announce an enhanced experience by enabling search functionality when linking to a GitHub pull request or commit. Search and select the desired repository and drill down to find and link to the specific pull request or commit. No more need for multiple window changes and copy/paste (although you still have that option).

Gif to demo add link.

Note

This feature is only available in the New Boards Hub preview.

If you're interested in getting access to this feature, send us an email directly along with your organization name (dev.azure.com/{organization name}).

New Boards Hub Improvements

With this release, we have introduce a range of enhancements to the New Boards Hub preview, focusing on accessibility and page reflow.

Here's an example of the page reflow changes that are adaptive up to 400% zoom.

Gif to demo new boards hub improvements.

Furthermore, we have rolled out performance enhancements across the work item form, boards, and backlogs pages. With these changes, you can expect New Boards to match the performance standards set with Old Boards.

Development and Deployment Controls

We now remove the Development and/or Deployment controls from the work item, depending on how your project is configured. For example, you might configure your project settings to turn off Repos and/or Pipelines.

Screenshots of DevOps services.

When you go to the work item, the corresponding Development and Deployment controls will be hidden from the form.

Screenshots of related work.

If you decide to connect a GitHub repo to Azure Boards, the Development control for GitHub repos will be displayed.

Screenshots of development control .

Azure Pipelines

Workload identity federation for Azure Resource Manager service connections is now generally available

In September, we announced the ability to configure Azure service connections without using a secret. Since then, many customers have adopted this feature and we're excited to announce this capability is now generally available.

If you aren't using Workload identity federation yet, you can take advantage of worry-free Azure service connections that don't have expiring secrets in the following ways:

To create a new Azure service connection using workload identity federation, select Workload identity federation (automatic) in the Azure service connection creation experience:

Screenshot of Workload identity federation (automatic).

To convert a previously created Azure service connection, select the "Convert" action after selecting the connection:

Screenshot of Convert action.

To convert multiple service connections, you can use automation for example, this PowerShell script:

#!/usr/bin/env pwsh
<# 
.SYNOPSIS 
    Convert multiple Azure Resource Manager service connection(s) to use Workload identity federation

.LINK
    https://aka.ms/azdo-rm-workload-identity-conversion

.EXAMPLE
    ./convert_azurerm_service_connection_to_oidc_simple.ps1 -Project <project> -OrganizationUrl https://dev.azure.com/<organization>
#> 
#Requires -Version 7.3

param ( 
    [parameter(Mandatory=$true,HelpMessage="Name of the Azure DevOps Project")]
    [string]
    [ValidateNotNullOrEmpty()]
    $Project,

    [parameter(Mandatory=$true,HelpMessage="Url of the Azure DevOps Organization")]
    [uri]
    [ValidateNotNullOrEmpty()]
    $OrganizationUrl
) 
$apiVersion = "7.1"
$PSNativeCommandArgumentPassing = "Standard" 

#-----------------------------------------------------------
# Log in to Azure
$azdoResource = "499b84ac-1321-427f-aa17-267ca6975798"
az login --allow-no-subscriptions --scope ${azdoResource}/.default
$OrganizationUrl = $OrganizationUrl.ToString().Trim('/')

#-----------------------------------------------------------
# Retrieve the service connection
$getApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints?authSchemes=ServicePrincipal&type=azurerm&includeFailed=false&includeDetails=true&api-version=${apiVersion}"
az rest --resource $azdoResource -u "${getApiUrl} " -m GET --query "sort_by(value[?authorization.scheme=='ServicePrincipal' && data.creationMode=='Automatic' && !(isShared && serviceEndpointProjectReferences[0].projectReference.name!='${Project}')],&name)" -o json `
        | Tee-Object -Variable rawResponse | ConvertFrom-Json | Tee-Object -Variable serviceEndpoints | Format-List | Out-String | Write-Debug
if (!$serviceEndpoints -or ($serviceEndpoints.count-eq 0)) {
    Write-Warning "No convertible service connections found"
    exit 1
}

foreach ($serviceEndpoint in $serviceEndpoints) {
    # Prompt user to confirm conversion
    $choices = @(
        [System.Management.Automation.Host.ChoiceDescription]::new("&Convert", "Converting service connection '$($serviceEndpoint.name)'...")
        [System.Management.Automation.Host.ChoiceDescription]::new("&Skip", "Skipping service connection '$($serviceEndpoint.name)'...")
        [System.Management.Automation.Host.ChoiceDescription]::new("&Exit", "Exit script")
    )
    $prompt = $serviceEndpoint.isShared ? "Convert shared service connection '$($serviceEndpoint.name)'?" : "Convert service connection '$($serviceEndpoint.name)'?"
    $decision = $Host.UI.PromptForChoice([string]::Empty, $prompt, $choices, $serviceEndpoint.isShared ? 1 : 0)

    if ($decision -eq 0) {

        Write-Host "$($choices[$decision].HelpMessage)"
    } elseif ($decision -eq 1) {
        Write-Host "$($PSStyle.Formatting.Warning)$($choices[$decision].HelpMessage)$($PSStyle.Reset)"
        continue 
    } elseif ($decision -ge 2) {
        Write-Host "$($PSStyle.Formatting.Warning)$($choices[$decision].HelpMessage)$($PSStyle.Reset)"
        exit 
    }

    # Prepare request body
    $serviceEndpoint.authorization.scheme = "WorkloadIdentityFederation"
    $serviceEndpoint.data.PSObject.Properties.Remove('revertSchemeDeadline')
    $serviceEndpoint | ConvertTo-Json -Depth 4 | Write-Debug
    $serviceEndpoint | ConvertTo-Json -Depth 4 -Compress | Set-Variable serviceEndpointRequest
    $putApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints/$($serviceEndpoint.id)?operation=ConvertAuthenticationScheme&api-version=${apiVersion}"
    # Convert service connection
    az rest -u "${putApiUrl} " -m PUT -b $serviceEndpointRequest --headers content-type=application/json --resource $azdoResource -o json `
            | ConvertFrom-Json | Set-Variable updatedServiceEndpoint
    
    $updatedServiceEndpoint | ConvertTo-Json -Depth 4 | Write-Debug
    if (!$updatedServiceEndpoint) {
        Write-Debug "Empty response"
        Write-Error "Failed to convert service connection '$($serviceEndpoint.name)'"
        exit 1
    }
    Write-Host "Successfully converted service connection '$($serviceEndpoint.name)'"
}

For more information, visit our documentation.

The Pipelines agent shows resource utilization issues more prominently

Last October we added the ability to track memory & disk space usage by the Pipelines agent.

To make customers aware, they may have resource constraints such as memory or disk space limitations on their agent, we made resource constraints more visible:

Screenshot of Limited memory and disk space warning.

If you see any of the above messages, this may be caused by a task using more resources than the agent is dimensioned for which may result in the agent not being responsive and failing a pipeline job:

"We stopped hearing from the agent"

In such cases, enable verbose logs to get more finer grained resource utilization messages and track where your agent ran out of resources. If you're using a Self-hosted agent, make sure your agent has adequate resources.

Out-of-band installation of Node 6 task runner

Azure Pipelines provides two versions of agent packages:

  • vsts-agent-* packages support tasks using Node 6 to run.
  • pipelines-agent-* packages do not support tasks that require Node 6 to run.

Customers that create Self-hosted agents can download these from the Pipeline agent releases page. The Node versions included with the agent are used to execute tasks. See Node runner versions.

After agent registration, agents installed from pipelines-agent-* packages will now download Node versions that are not included with the agent and not blocked under 'Task restrictions' in organization settings. This allows customers to use pipelines-agent-* agent packages and control the installation of Node 6 with 'Task restrictions' in organization settings.

Deferred approval

Approvals can be used to sign off on a deployment. However, there are situations when the time when the approval is given and the time the deployment should start don't match. For example, for the particular deployment you review, you know it's an out-of-bounds one. Imagine it can't proceed immediately, rather it should take place during the night.

To cover such scenarios, we've added the option to defer approvals for YAML pipelines. Now, you can approve a pipeline run and specify when should the approval be effective.

Screenshot of approve a pipeline run.

When you select Defer approval, you can configure the time when the approval becomes effective.

Screenshot of Defer approval.

Screenshot of after_approval_deferred.

The approval shows up as deferred in the checks panel. After the deferred-to time, the approval is effective.

Screenshot of approval is effective.

Sequencing approvals and checks

With this sprint, you're able to specify the order in which approvals and checks run.

Approvals and checks allow you to control deployments to production. For example, you can specify that only pipelines that run on the main branch of a repository are allowed to use a production ARM service connection. Furthermore, you can require human approval and that the system passes a performance check.

Up until today, all approvals, and checks ran in parallel, except for exclusive lock. This meant that if your deployment process required performance checks to pass before manual approval is given, you couldn't enforce this in Azure Pipelines. You had to rely on approval instructions and internal process documentation.

With this sprint, we're introducing sequencing in Approvals and Checks. There are now five categories of Approvals and Checks:

  1. Static checks: Branch control, Required template, and Evaluate artifact
  2. Pre-dynamic checks Approval
  3. Dynamic checks: Approval, Invoke Azure Function, Invoke REST API, Business Hours, Query Azure Monitor alerts
  4. Post-dynamic checks Approval
  5. Exclusive lock

Screenshot of add check.

The order is shown also in the Approvals and checks tab.

Screenshot of approvals and checks tab.

Within each category, the checks run in parallel. That is, if you have an Invoke Azure Function check and a Business hours check, they run at the same time.

Screenshot of checks for deploy.

Check categories run one by one and if one fails, the rest of the checks aren't executed. This means that if you have a Branch control check and an Approval, if the Branch control fails, the Approval will fail, too. So no needless emails will be sent.

Screenshot of checks for deploy fail.

You can sign off on a deployment after all dynamic checks ran, using a post-dynamic checks Approval, or do a manual validation before proceeding with dynamic checks, using a pre-dynamic checks Approval.

Validate and Save by default when editing YAML pipelines

An incorrect YAML pipeline can lead to wasted time and effort. To improve your pipeline editing productivity, we're changing the Save button in the editor to also do YAML validation.

Screenshot of new button.

Screenshot of validate and save.

If your pipeline has errors, you'll still be able to save it.

Screenshot of pipeline is valid.

Screenshot of errors detected.

We also improved the Validate experience, so you can see the errors in a list that's easier to understand.

Screenshot of errors list.

Azure Repos

Prevention for unauthorized users to configure pipeline as a Build Policy

Prevention for unauthorized users to configure pipeline as a Build Policy

Previously, when you've been adding a new build policy, you could configure to run any pipeline from the drop-down list (including the pipelines you had no Queue builds permission for). Similarly, you could edit the existing build policy even if that was configured to run the pipeline you had no Queue builds permission for.

Now we're preventing users from doing so. If a user is denied to Queue builds permission for given pipeline, then that pipeline will be shown as disabled (greyed out) in the drop-down when adding new build policy.

See the image below showing the pipeline named "Sandbox" with Queue builds permission being denied.

Screenshot of permissions for Sandbox.

See the image below showing the pipeline named "Sandbox" disabled (greyed out) in the drop-down when user with denied Queue builds permission is trying to add new build policy.

Screenshot of add build policy.

When the build policy configured to run the pipeline named "Sandbox" already exists, then the user with no Queue builds permission won't be able to edit or view the build policy. This case is shown on the following image.

Screenshot of build validation.

When you try to delete this policy the pop-up dialog asking for deletion confirmation will be shown.

Screenshot of confirm deletion.

These changes also apply to any API calls that result in either creation or editing of the build policy. When any of these actions is run using a user identity with no Queue builds permission, then the call will fail returning back the appropriate error code and the error message saying “TFS.WebApi.Exception: TF401027: You need the QueueBuild permission on this pipeline to perform this action.”.

Deletion of a build policy done via API using a user identity with no Queue builds permission will succeed and there will be no warning or prevention done (no changes in how the deletion via API works).

Azure Artifacts

Support for Rust Crates is generally available

Beginning February 16, 2024, Rust Crates support will become a generally available feature for Azure Artifacts. Billing meters will be activated, using the same pricing model that applies to the other supported protocols.

Azure Artifacts support for npm audit

Azure Artifacts now supports npm audit and npm audit fix commands. This feature enables users to analyze and fix their project's vulnerabilities by automatically updating insecure package versions. To learn more visit, Use npm audit to detect and fix package vulnerabilities.

Next steps

Note

These features will roll out over the next two to three weeks.

Head over to Azure DevOps and take a look.

Go to Azure DevOps

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.

Make a suggestion

You can also get advice and your questions answered by the community on Stack Overflow.

Thanks,

Dan Hellem