Azure 资源管理器服务连接的工作负荷标识联合正式发布

我们很高兴地宣布,工作负载标识联合现已在 Azure Pipelines 中正式发布! 无需在 Azure 服务连接中管理机密和证书,即可享受简化的体验。

通过此更新,我们还预览了一项新功能,作为增强的 GitHub 与 Azure Boards 集成的一部分。 现在可以直接链接到 GitHub 拉取请求或提交。 在窗口或复制/粘贴之间不再切换。 只需选择所需的存储库,找到所需的拉取请求或提交,然后将其链接!

请查看发行说明,了解有关这些功能的详细信息。

常规

适用于 Azure DevOps 的 GitHub Advanced Security

Azure Boards

Azure Pipelines

Azure Repos

Azure Artifacts

常规

备用凭据弃用的最终通知

备用凭据 于 2020 年 3 月正式弃用,但一些现有用户被祖父使用其现有备用凭据。 自 2024 年 1 月起,我们已完全弃用所有备用凭据。为了避免任何潜在的中断,请切换到我们提供的 一种可用的身份验证机制 ,例如个人访问令牌或托管标识。

Azure Devops OAuth 自助服务机密轮换

每五年更新 Azure DevOps OAuth 应用的客户端密码至关重要,以确保持续生成使用 Azure DevOps API 所需的访问和刷新令牌。 随着客户端机密即将到期,你现在可以独立生成一个新密钥,从而为团队提供自由来管理它,而无需依赖客户支持。 这种计划机密轮换的灵活性可最大程度地减少客户因机密过期而等待更换的中断时间。

Screenshot of Select a geography.

在可通过此处的配置文件访问的每个 Azure DevOps 应用页面中查找此新功能。 在 Azure DevOps OAuth 指南详细了解这一新步骤。

适用于 Azure DevOps 的 GitHub Advanced Security

警报详细信息视图中现在提供的代码片段

代码扫描和机密扫描警报的警报详细信息页现在显示代码片段,这些代码片段标记了发生警报的一行或多行代码。 若要转到 Azure DevOps 存储库中的原始文件,请单击代码片段上方的文件名。

Screenshot of case-sensitive middleware path.

警报概述中显示的截断机密

截断的、检测到的任何机密的最后六个字符现在显示在机密警报概述屏幕中。 如果具有相同机密类型的多个机密公开,则此功能非常有用,使你能够快速识别特定机密的生存位置。

Screenshot of secret alerts list.

为代码扫描警报添加了更多警报严重性

现在,CodeQL quality 查询 Error中的警报结果存在新的警报严重性, Warning以及 Note 严重性。 每个质量警报严重性都有自己的锁屏提醒和颜色来表示缩放严重性。 还可以筛选每个严重性,类似于lowcritical安全警报的严重性规模。

Screenshot of code scanning alerts list and severity filter.

用于 Azure DevOps 的 GitHub 高级安全性所需的链接 Azure 订阅

如果以前为 Azure DevOps 组织中没有链接的 Azure 订阅的存储库启用了高级安全性,你可能会注意到高级安全会自动在这些存储库上禁用自身。 若要重新启用高级安全性,请将关联的 Azure 订阅添加到组织。 有关如何添加或更改订阅的详细信息,请参阅 “更改 Azure 订阅”。

高级安全性 API更新

最近发布对高级安全性 API的各种更新:

  • GET 警报 API 现在支持一个新参数, ModifiedSince用于返回警报的增量列表,并仅返回自此日期以来修改的警报。 有关详细信息,请参阅 “警报 - 列表”。
  • GET SARIFs API 现在返回特定的上传错误,以帮助排查任何 SARIF 上传失败。 有关详细信息,请参阅 SARIF
  • 有两个新终结点可用于提取或更新组织或项目的高级安全启用状态。 这两个终结点返回启用了高级安全性的存储库列表。 有关详细信息,请参阅 组织 - 启用项目 - 启用
  • 有两个新终结点可以获取组织或项目的主动提交者计数的估计值,以反映估计的高级安全计量使用量可能会花费什么。 有关详细信息,请参阅 组织计量使用情况估算项目计量使用情况估算

高级安全权限现已永久显示

过去,仅当启用了高级安全性时,三个高级安全权限位才会显示为每个存储库可分配的权限。 现在,这些权限在“存储库>安全权限”窗格中默认可用,无需启用高级安全性即可分配。

Screenshot of Advanced Security permissions.

Azure Boards

有两个选项可用于将工作项与 GitHub 连接拉取请求或提交。 可以在拉取请求中使用 AB# 语法,也可以直接从工作项链接它。 目前,此过程涉及复制 GitHub 的 URL 拉取请求并在添加链接时粘贴它。 这需要打开多个窗口并在 GitHub 和 Azure DevOps 之间切换。

在此冲刺中,我们很高兴在链接到 GitHub 拉取请求或提交时启用搜索功能来宣布增强的体验。 搜索并选择所需的存储库并向下钻取以查找并链接到特定拉取请求或提交。 不再需要多个窗口更改和复制/粘贴(尽管仍具有该选项)。

Gif to demo add link.

注意

此功能仅在新版板中心预览版可用。

如果你有兴趣获取此功能的访问权限,请直接与组织名称(dev.azure.com/{组织名称})起发送电子邮件。

新版块中心改进

在此版本中,我们引入了一系列对 New Boards Hub 预览版的增强功能,重点介绍辅助功能和页面重排。

下面是页面重排更改的示例,该更改自适应高达 400% 缩放。

Gif to demo new boards hub improvements.

此外,我们在工作项窗体、板和积压工作页中推出了性能增强功能。 通过这些更改,可以期待新版符合使用旧版设置的性能标准。

开发和部署控制

现在,根据项目的配置方式,从工作项中删除开发和/或部署控件。 例如,可以将项目设置配置为关闭 Repos 和/或 Pipelines。

Screenshots of DevOps services.

转到工作项时,相应的开发和部署控件将从窗体中隐藏。

Screenshots of related work.

如果决定将 GitHub 存储库连接到 Azure Boards,则会显示 GitHub 存储库的开发控件。

Screenshots of development control .

Azure Pipelines

Azure 资源管理器服务连接的工作负荷标识联合现已正式发布

今年9月,我们 宣布 能够在不使用机密的情况下配置 Azure 服务连接。 此后,许多客户都采用了此功能,我们很高兴地宣布此功能现已正式发布。

如果尚未使用工作负荷标识联合,可以采用以下方式利用没有过期机密的免费 Azure 服务连接:

若要使用工作负荷标识联合创建新的 Azure 服务连接,请在 Azure 服务连接创建体验中选择工作负荷标识联合身份验证(自动):

Screenshot of Workload identity federation (automatic).

若要转换以前创建的 Azure 服务连接,请在选择连接后选择“转换”操作:

Screenshot of Convert action.

若要转换多个服务连接,可以使用自动化,例如,此 PowerShell 脚本:

#!/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)'"
}

有关详细信息,请访问我们的 文档

Pipelines 代理更突出地显示资源利用率问题

去年 10 月 ,我们添加了跟踪 Pipelines 代理的内存和磁盘空间使用情况的功能。

为了让客户知道,他们可能有资源约束(例如内存或磁盘空间限制)在其代理上,我们使资源约束更加明显:

Screenshot of Limited memory and disk space warning.

如果看到上述任何消息,这可能是由使用比代理维度更多的资源的任务造成的,这可能会导致代理无法响应,并且管道作业失败:

“我们停止听到代理的听觉”

在这种情况下,启用 详细日志 以获取更精细的资源利用率消息,并跟踪代理耗尽资源的位置。 如果使用自承载代理,请确保代理有足够的资源。

Node 6 任务运行程序带外安装

Azure Pipelines 提供两个版本的代理包:

  • vsts-agent-* 包支持使用 Node 6 运行的任务。
  • pipelines-agent-* 包不支持需要 Node 6 运行的任务。

创建自承载代理的客户可以从管道代理发布页下载这些代理。 代理附带的 Node 版本用于执行任务。 请参阅 Node 运行程序版本

代理注册后,从 pipelines-agent-* 包安装的代理现在将下载未包含在代理中的 Node 版本,并且不会在组织设置中的“任务限制”下阻止这些版本。 这样,客户就可以使用 pipelines-agent-* 代理包,并在组织设置中使用“任务限制”控制 Node 6 的安装。

延迟审批

审批可用于在部署上注销。 但是,在某些情况下,给定审批的时间和部署开始的时间不匹配。 例如,对于你查看的特定部署,你知道它是一个超出边界的部署。 想象一下,它不能立即继续,而是应该在夜间进行。

为了涵盖此类方案,我们添加了推迟 YAML 管道审批的选项。 现在,可以批准管道运行,并指定审批何时生效。

Screenshot of approve a pipeline run.

选择“延迟审批时,可以配置审批生效的时间。

Screenshot of Defer approval.

Screenshot of after_approval_deferred.

审批在检查面板中显示为延迟。 延迟到时间后,审批生效。

Screenshot of approval is effective.

序列化审批和检查

使用此冲刺,可以指定审批和检查运行的顺序。

审批和检查允许你控制部署到生产环境的部署。 例如,可以指定仅允许在存储库分支上运行 main 的管道使用生产 ARM 服务连接。 此外,你可以要求人工批准,并且系统通过性能检查。

直到今天,除独占锁外,所有审批和检查都并行运行。 这意味着,如果你的部署过程需要性能检查在手动批准之前通过,则无法在 Azure Pipelines 中强制实施此操作。 必须依赖审批说明和内部流程文档。

通过此冲刺,我们将在审批和检查中引入排序。 现在有五类审批和检查:

  1. 静态检查:分支控件、必需模板和评估项目
  2. 预动态检查审批
  3. 动态检查:审批、调用 Azure 函数、调用 REST API、工作时间、查询 Azure Monitor 警报
  4. 动态检查审批
  5. 排他锁

Screenshot of add check.

订单也会显示在“审批”和“检查”选项卡中。

Screenshot of approvals and checks tab.

在每个类别中,检查并行运行。 也就是说,如果你有一个调用 Azure 函数检查和一个工作时间检查,则它们同时运行。

Screenshot of checks for deploy.

检查类别逐个运行,如果一个失败,则不会执行其余检查。 这意味着,如果你有分支控件检查和审批,如果分支控件失败,审批也会失败。 因此,不会发送不需要的电子邮件。

Screenshot of checks for deploy fail.

在使用动态检查审批后,可以在运行所有动态检查后、使用动态检查审批后登录部署,或者在使用动态检查之前执行手动验证,并使用预动态检查审批。

编辑 YAML 管道时,默认验证并保存

错误的 YAML 管道可能会导致浪费时间和精力。 为了提高管道编辑工作效率,我们正在将编辑器中的“保存”按钮更改为执行 YAML 验证。

Screenshot of new button.

Screenshot of validate and save.

如果管道有错误,仍可以保存它。

Screenshot of pipeline is valid.

Screenshot of errors detected.

我们还改进了 “验证” 体验,因此你可以在更易于理解的列表中看到错误。

Screenshot of errors list.

Azure Repos

防止未经授权的用户将管道配置为生成策略

防止未经授权的用户将管道配置为生成策略

以前,添加新生成策略时,可以配置为从下拉列表运行任何管道(包括没有 队列生成权限的 管道)。 同样,即使已配置为运行没有 队列生成权限的 管道,也可以编辑现有的生成策略。

现在,我们阻止用户这样做。 如果用户拒绝对 给定管道的 队列生成权限,则在添加新生成策略时,该管道将在下拉列表中显示为禁用(灰显)。

请参阅下图,其中显示了名为“沙盒”的管道,其中 队列生成 权限被拒绝。

Screenshot of permissions for Sandbox.

请参阅下图,其中显示了在尝试添加新生成策略时,下拉列表中名为“沙盒”的管道已禁用(灰显)。

Screenshot of add build policy.

当配置为运行名为“Sandbox”的管道的生成策略已存在时,没有 队列生成 权限的用户将无法编辑或查看生成策略。 下图显示了这种情况。

Screenshot of build validation.

当用户尝试删除此类策略时,将显示要求删除确认的弹出对话框。

Screenshot of confirm deletion.

这些更改也适用于导致创建或编辑生成策略的任何 API 调用。 如果其中任一操作都使用没有 队列生成 权限的用户标识运行,则调用将失败返回相应的错误代码和错误消息,指出 “TFS.WebApi.Exception: TF401027: 需要此管道上的 QueueBuild 权限才能执行此操作。

使用 user identity 没有 队列生成 权限的 API 删除通过 API 完成的生成策略将成功,并且不会发出警告或阻止操作(不会更改通过 API 删除的方式)。

Azure Artifacts

对 Rust 箱的支持已正式发布

从 2024 年 2 月 16 日开始,Rust Crates 支持将成为 Azure Artifacts 的正式发布功能。 将使用适用于其他受支持协议的相同定价模型激活计费计量。

对 npm 审核的 Azure Artifacts 支持

Azure Artifacts 现在支持 npm auditnpm audit fix 命令。 此功能使用户能够通过自动更新不安全的包版本来分析和修复其项目的漏洞。 若要了解详细信息, 请使用 npm 审核来检测和修复包漏洞

后续步骤

注意

这些功能将在未来两到三周内推出。

前往 Azure DevOps 并了解一下。

如何提供反馈

我们很想听听你对这些功能的看法。 使用帮助菜单报告问题或提供建议。

Make a suggestion

你还可以在 Stack Overflow 上获得社区的建议和问题的答案。

此致

Dan Hellem