次の方法で共有

Azure Resource Manager サービス接続のワークロード ID フェデレーションの一般提供

  • [アーティクル]

ワークロード ID フェデレーションが Azure Pipelines で一般公開されたことをお知らせします。 Azure サービス接続でシークレットと証明書を管理する必要なく、合理化されたエクスペリエンスを楽しむことができます。

この更新プログラムでは、強化された GitHub と Azure Boards の統合の一環として、新機能もプレビューしています。 GitHub プル要求またはコミットに直接リンクできるようになりました。 ウィンドウまたはコピー/貼り付けを切り替える必要はありません。 必要なリポジトリを選択し、必要なプル要求またはコミットを見つけてリンクするだけです。

これらの機能の詳細については、リリース ノートを参照してください。

全般

GitHub Advanced Security for Azure DevOps

Azure Boards

Azure Pipelines

Azure Repos

Azure Artifacts

全般

代替資格情報の廃止に関する最終通知

代替資格情報 2020 年 3 月に廃止されましたが既存のユーザーの中には、既存の代替資格情報を継続的に使用しているユーザーもいました。 2024 年 1 月の時点で、すべての代替資格情報は完全に非推奨になりました。中断の可能性を回避するには、個人用アクセス トークンやマネージド ID など使用可能な認証メカニズムのいずれかに切り替えます。

Azure Devops OAuth のセルフサービス シークレット ローテーション

5 年ごとに、Azure DevOps OAuth アプリの Client シークレット を更新して、Azure DevOps API を利用するために必要なアクセス トークンと更新トークンを継続的に生成することが不可欠です。 Client シークレットが有効期限に近づくにつれて、新しいシークレットを個別に生成できるようになりました。これにより、チームはカスタマー サポートに頼らずに自由に管理できます。 シークレットローテーションをスケジュールする柔軟性により、期限切れのシークレットが原因で交換を待つ顧客の潜在的な停止時間を最小限に抑えることができます。

[地域の選択] のスクリーンショット。

この新しい機能は、Azure DevOps アプリの各ページで探します。このページでは、 プロファイルからアクセスできます。 この新しい手順の詳細については、 Azure DevOps OAuth ガイドを参照してください。

GitHub Advanced Security for Azure DevOps

アラートの詳細ビューでコード スニペットを使用できるようになりました

コード スキャンとシークレット スキャン アラートのアラートの詳細ページに、アラートが発生した 1 行以上のコードをマークするコード スニペットが表示されるようになりました。 Azure DevOps リポジトリ内の元のファイルに移動するには、コード スニペットの上にあるファイル名をクリックします。

大文字と小文字が区別されるミドルウェア パスのスクリーンショット。

アラートの概要に表示される切り捨てられたシークレット

検出されたシークレットの最後の 6 文字が、シークレットアラートの概要画面に表示されるようになりました。 この機能は、同じ種類のシークレットが複数公開されている場合に役立ちます。これにより、特定のシークレットが存在する場所をすばやく特定できます。

シークレット アラートの一覧のスクリーンショット。

コード スキャン アラートに追加されたアラートの重大度の追加

Error、Warning、およびNoteの重大度として、CodeQL quality クエリからのアラート結果に対する新しいアラートの重大度が存在するようになりました。 品質アラートの重大度にはそれぞれ、スケーリングの重大度を示す独自のバッジと色があります。 セキュリティ アラートの重大度スケールをcriticalするlowと同様に、これらの重大度ごとにフィルター処理することもできます。

コード スキャンアラートの一覧と重大度フィルターのスクリーンショット。

GitHub Advanced Security for Azure DevOps の有効化に必要なリンクされた Azure サブスクリプション

リンクされた Azure サブスクリプションを持たない Azure DevOps 組織のリポジトリに対して Advanced Security を以前に有効にしていた場合、Advanced Security がそれらのリポジトリで自動的に無効になっていることがわかります。 Advanced Security を再度有効にするには、関連付けられている Azure サブスクリプションを組織に追加します。 サブスクリプションを追加または変更する方法の詳細については、「 Change Azure サブスクリプション」を参照してください。

高度なセキュリティ API の更新

最近出荷された Advanced Security API のさまざまな更新プログラム:

  • GET Alerts API では、アラートの増分リストを返し、この日付以降に変更されたアラートのみを返す新しいパラメーター ( ModifiedSince) がサポートされるようになりました。 詳細については、「 Alerts - List」を参照してください。
  • 組織またはプロジェクトの高度なセキュリティ有効化状態をフェッチまたは更新するための新しいエンドポイントが 2 つあります。 どちらのエンドポイントも、Advanced Security が有効になっているリポジトリの一覧を返します。 詳細については、「 Org - Enablement または Project - Enablement を参照してください。
  • 組織またはプロジェクトのアクティブなコミッター数の見積もりをフェッチして、高度なセキュリティメーターの推定使用量を反映する新しいエンドポイントが 2 つあります。 詳細については、「 Org Meter Usage Estimate または Project Meter Usage Estimate」を参照してください。

セキュリティの高度なアクセス許可が完全に表示されるようになりました

以前は、Advanced Security が有効になっている場合、3 つの Advanced Security アクセス許可ビットはリポジトリごとの割り当て可能なアクセス許可としてのみ存在していました。 これで、これらのアクセス許可は既定で Repositories > Security アクセス許可ペインで使用でき、Advanced Security を有効にしなくても割り当てることができます。

高度なセキュリティアクセス許可のスクリーンショット。

Azure Boards

作業項目を GitHub のプル要求またはコミットに接続するには、2 つのオプションがあります。 プル要求で AB# 構文を使用することも、作業項目から直接リンクすることもできます。 現在、このプロセスでは、GitHub pull request の URL をコピーし、リンクを追加するときに貼り付ける必要があります。 これには、複数のウィンドウを開き、GitHub と Azure DevOps を切り替える必要があります。

このスプリントでは、GitHub プル要求またはコミットにリンクするときに検索機能を有効にすることで、エクスペリエンスが強化されたことをお知らせします。 目的のリポジトリを検索して選択し、ドリルダウンして特定のプル要求またはコミットを見つけてリンクします。 複数のウィンドウの変更やコピー/貼り付けを行う必要はありません (ただし、そのオプションはまだあります)。

GIF を使用してデモ用のリンクを追加します。

Note

この機能は、 New Boards Hub プレビューでのみ使用できます。

この機能へのアクセスに関心がある場合は、組織名(dev.azure.com/{組織名})と共にemail を直接送信してください。

新しい Boards Hub の機能強化

このリリースでは、アクセシビリティとページリフローに重点を置いて、New Boards Hub プレビューにさまざまな機能強化を導入しました。

最大 400% のズームに適応するページ リフローの変更の例を次に示します。

Gif を使用して新しいボード ハブの機能強化をデモします。

さらに、作業項目のフォーム、ボード、バックログの各ページでパフォーマンスの向上をロールアウトしました。 これらの変更により、新しいボードは、古いボードで設定されたパフォーマンス標準に一致することが期待できます。

開発と展開の制御

プロジェクトの構成方法に応じて、作業項目から開発コントロールまたは配置コントロールを削除します。 たとえば、リポジトリやパイプラインをオフにするようにプロジェクト設定を構成できます。

DevOps サービスのスクリーンショット。

作業項目に移動すると、対応する開発コントロールと配置コントロールがフォームに表示されなくなります。

関連する作業のスクリーンショット。

GitHub リポジトリを Azure Boards に 接続する場合 GitHub リポジトリの開発コントロールが表示されます。

開発コントロールのスクリーンショット。

Azure Pipelines

Azure Resource Manager サービス接続のワークロード ID フェデレーションが一般公開されました

9 月シークレットを使用せずに Azure サービス接続を構成する機能が発表されました。 それ以来、多くのお客様がこの機能を採用しており、この機能が一般公開されたことをお知らせします。

ワークロード ID フェデレーションをまだ使用していない場合は、次の方法で、期限切れのシークレットがない心配のない Azure サービス接続を利用できます。

ワークロード ID フェデレーションを使用して新しい Azure サービス接続を作成するには、Azure サービス接続作成エクスペリエンスでワークロード ID フェデレーション (自動) を選択します。

ワークロード ID フェデレーション (自動) のスクリーンショット。

以前に作成した Azure サービス接続を変換するには、接続を選択した後に [変換] アクションを選択します。

変換アクションのスクリーンショット。

複数のサービス接続を変換するには、次の 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 エージェントによるメモリとディスク領域の使用量を追跡する機能が追加されました。

お客様が認識できるように、エージェントのメモリやディスク領域の制限などのリソース制約がある可能性があるため、リソースの制約がより見えやすくなっています。

制限付きメモリとディスク領域の警告のスクリーンショット。

上記のメッセージのいずれかが表示された場合、これは、エージェントがディメンション化されているよりも多くのリソースを使用しているタスクが原因で発生する可能性があります。その結果、エージェントが応答せず、パイプライン ジョブが失敗する可能性があります。

「エージェントからの聞き取りを停止しました」

このような場合は、 verbose ログを有効にして より詳細なリソース使用率メッセージを取得し、エージェントがリソースを使い果たした場所を追跡します。 セルフホステッド エージェントを使用している場合は、エージェントに十分なリソースがあることを確認します。

ノード 6 タスク ランナーの帯域外インストール

Azure Pipelines には、次の 2 つのバージョンのエージェント パッケージが用意されています。

  • vsts-agent-* パッケージは、Node 6 を使用して実行するタスクをサポートします。
  • pipelines-agent-* パッケージは、Node 6 の実行を必要とするタスクをサポートしていません。

セルフホステッド エージェントを作成するお客様は、パイプライン エージェント リリース ページからダウンロードできます。 エージェントに含まれる Node バージョンは、タスクの実行に使用されます。 Node ランナーのバージョンを参照してください。

エージェントの登録後、 pipelines-agent-* パッケージからインストールされたエージェントは、エージェントに含まれていないノード バージョンをダウンロードし、組織の設定の [タスクの制限] でブロックされなくなります。 これにより、お客様は pipelines-agent-* エージェント パッケージを使用し、組織の設定で "タスク制限" を使用して Node 6 のインストールを制御できます。

遅延承認

承認を使用して、デプロイでサインオフできます。 ただし、承認が与えられ、デプロイを開始する時刻が一致しない場合があります。 たとえば、確認する特定のデプロイでは、それが範囲外であることがわかります。 それはすぐに進むのではなく、夜の間に行われるべきであると想像してください。

このようなシナリオに対応するために、YAML パイプラインの承認を延期するオプションを追加しました。 これで、パイプラインの実行を承認し、承認を有効にするタイミングを指定できます。

パイプラインの実行を承認するスクリーンショット。

Defer 承認を選択すると、承認が有効になる時間を構成できます。

承認の延期のスクリーンショット。

after_approval_deferredのスクリーンショット。

承認は、チェック パネルに遅延として表示されます。 遅延時間が経過すると、承認が有効になります。

承認のスクリーンショットが有効です。

承認とチェックのシーケンス処理

このスプリントを使用すると、承認とチェックを実行する順序を指定できます。

承認とチェック 運用環境へのデプロイを制御できます。 たとえば、リポジトリの main ブランチで実行されるパイプラインのみが運用 ARM サービス接続の使用を許可されるように指定できます。 さらに、人的承認を要求し、システムがパフォーマンス チェックに合格することを要求できます。

現在まで、排他ロックを除き、すべての承認とチェックが並列で実行されました。 つまり、デプロイ プロセスで、手動承認が与えられる前にパフォーマンス チェックが成功する必要がある場合、Azure Pipelines でこれを適用することはできません。 承認の指示と内部プロセスのドキュメントに依存する必要がありました。

このスプリントでは、承認とチェックのシーケンス処理を導入しています。 承認とチェックには、次の 5 つのカテゴリがあります。

  1. 静的チェック：分岐制御、必要なテンプレートと評価アーティファクト
  2. 動的前チェックの承認
  3. ダイナミックチェック：承認、Azure関数の呼び出し、REST APIの呼び出し、営業時間、Azure Monitorアラートの照会
  4. 動的チェック後の承認
  5. 排他ロック

チェックの追加のスクリーンショット。

注文は[承認とチェック]タブにも表示されます。

[承認とチェック] タブのスクリーンショット。

各カテゴリ内では、チェックは並列で実行されます。 つまり、Azure 関数の呼び出しチェックと営業時間チェックがある場合は、同時に実行されます。

デプロイのチェックのスクリーンショット。

チェック カテゴリは 1 つずつ実行され、失敗した場合、残りのチェックは実行されません。 つまり、ブランチ コントロール チェックと承認がある場合、ブランチ コントロールが失敗した場合、承認も失敗します。 そのため、不要なメールは送信されません。

デプロイ失敗のチェックのスクリーンショット。

動的チェック後の承認を使用して、すべての動的チェックが実行された後にデプロイでサインオフするか、動的チェックを続行する前に手動検証を実行して、事前動的チェックの承認を使用できます。

YAML パイプラインの編集時に既定で検証と保存を行う

YAML パイプラインが正しくないと、時間と労力が無駄になる可能性があります。 パイプラインの編集の生産性を向上させるために、エディターの Save ボタンを変更して、YAML 検証も行います。

新しいボタンのスクリーンショット。

検証と保存のスクリーンショット。

パイプラインにエラーがある場合でも、それを保存できます。

パイプラインのスクリーンショットが有効です。

エラーが検出されたスクリーンショット。

また、 Validate エクスペリエンスも改善され、わかりやすい一覧でエラーを確認できるようになりました。

エラー一覧のスクリーンショット。

Azure Repos

承認されていないユーザーがビルド ポリシーとしてパイプラインを構成するための防止

承認されていないユーザーがビルド ポリシーとしてパイプラインを構成するための防止

以前は、新しいビルド ポリシーを追加するときに、ドロップダウン リストから任意のパイプラインを実行するように構成できました ( Queue ビルド アクセス許可がなかったパイプラインを含む)。 同様に、 Queue ビルド アクセス許可がないパイプラインを実行するように構成されている場合でも、既存のビルド ポリシーを編集できます。

これで、ユーザーがこれを行うのを防ぎます。 ユーザーが特定のパイプラインのビルドアクセス許可拒否された場合、新しいビルド ポリシーを追加すると、そのパイプラインはドロップダウンに無効 (灰色表示) として表示されます。

Queue ビルドアクセス許可が拒否されている "Sandbox" という名前のパイプラインを示す下の画像を参照してください。

サンドボックスのアクセス許可のスクリーンショット。

Queue ビルドが拒否されたユーザーがアクセス許可を持つユーザーが新しいビルド ポリシーを追加しようとしている場合に、ドロップダウンで "Sandbox" が無効 (灰色表示) されたパイプラインを示す下の図を参照してください。

ビルド ポリシーの追加のスクリーンショット。

"Sandbox" という名前のパイプラインを実行するように構成されたビルド ポリシーが既に存在する場合、 Queue ビルドを持たないユーザーは アクセス許可でビルド ポリシーを編集または表示できなくなります。 このケースを次の図に示します。

ビルド検証のスクリーンショット。

このポリシーを削除しようとすると、削除の確認を求めるポップアップ ダイアログが表示されます。

削除の確認のスクリーンショット。

これらの変更は、ビルド ポリシーの作成または編集を行う API 呼び出しにも適用されます。 Queue ビルドアクセス許可のないユーザー ID を使用してこれらのアクションを実行すると、呼び出しは適切なエラー コードと、このアクションを実行するには、このパイプラインに対する QueueBuild アクセス許可が必要であることを示すエラー メッセージ“TFS.WebApi.Exception: TF401027:返されません。

Queue ビルドのないuser identityを使用して API 経由で実行されたビルド ポリシーの削除アクセス許可は成功し、警告や防止は行われません (API による削除のしくみに変更はありません)。

Azure Artifacts

Rust クレートのサポートが一般公開されました

2024 年 2 月 16 日から、Rust Crates のサポートは Azure Artifacts で一般公開される機能になります。 課金メーターは、サポートされている他のプロトコルに適用されるのと同じ価格モデルを使用してアクティブ化されます。

npm 監査に対する Azure Artifacts のサポート

Azure Artifacts では、 npm audit コマンドと npm audit fix コマンドがサポートされるようになりました。 この機能を使用すると、ユーザーは安全でないパッケージバージョンを自動的に更新することで、プロジェクトの脆弱性を分析して修正できます。 詳細については、 npm 監査を使用してパッケージの脆弱性を検出して修正します。

次のステップ

Note

これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。

Azure DevOps に向かい、見てみましょう。

Azure DevOps に移動する

フィードバックの提供方法

これらの機能に関するご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。

ご提案の送信

Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。

よろしくお願いします。

Dan Hellem