Azure Resource Manager サービス接続のワークロード ID フェデレーションの一般提供
ワークロード ID フェデレーションが Azure Pipelines で一般公開されたことをお知らせします。 Azure サービス接続でシークレットと証明書を管理する必要なく、合理化されたエクスペリエンスを楽しむことができます。
この更新プログラムでは、強化された GitHub と Azure Boards の統合の一環として、新機能もプレビューしています。 GitHub プル要求またはコミットに直接リンクできるようになりました。 ウィンドウまたはコピー/貼り付けを切り替える必要はありません。 必要なリポジトリを選択し、必要なプル要求またはコミットを見つけてリンクするだけです。
これらの機能の詳細については、リリース ノートを参照してください。
全般
Azure DevOps 用の GitHub Advanced Security
- アラートの詳細ビューでコード スニペットを使用できるようになりました
- アラートの概要に表示される切り捨てられたシークレット
- コード スキャン アラートに追加されたアラートの重大度の追加
- GitHub Advanced Security for Azure DevOps の有効化に必要なリンクされた Azure サブスクリプション
- 高度なセキュリティ API の更新
- セキュリティの高度なアクセス許可が完全に表示されるようになりました
Azure Boards
Azure Pipelines
- Azure Resource Manager サービス接続のワークロード ID フェデレーションが一般公開されました
- ノード 6 タスク ランナーの帯域外インストール
- 遅延承認
- 承認とチェックのシーケンス処理
- YAML パイプラインの編集時に既定で検証と保存を行う
Azure Repos
Azure Artifacts
全般
代替資格情報の廃止に関する最終通知
代替資格情報は 2020 年 3 月に正式に非推奨になりましたが、一部の既存のユーザーは、既存の代替資格情報を継続的に使用する必要がありました。 2024 年 1 月の時点で、すべての代替資格情報は完全に非推奨になりました。中断の可能性を回避するには、個人用アクセス トークンやマネージド ID など、提供されている使用可能な認証メカニズムのいずれかに切り替えます。
Azure Devops OAuth のセルフサービス シークレット ローテーション
5 年ごとに、Azure DevOps OAuth アプリのクライアント シークレットを更新して、Azure DevOps API を利用するために必要なアクセス トークンと更新トークンを継続的に生成することが不可欠です。 クライアント シークレットの有効期限が近づくと、新しいシークレットを個別に生成できるようになり、チームはカスタマー サポートに頼らずに自由に管理できるようになります。 シークレットローテーションをスケジュールする柔軟性により、期限切れのシークレットが原因で交換を待つ顧客の潜在的な停止時間を最小限に抑えることができます。
この新しい機能は、ここでプロファイルからアクセスできる Azure DevOps アプリの各ページで探します。 この新しい手順の詳細については、Azure DevOps OAuth ガイドを参照してください。
Azure DevOps 用の GitHub Advanced Security
アラートの詳細ビューでコード スニペットを使用できるようになりました
コード スキャンとシークレット スキャン アラートのアラートの詳細ページに、アラートが発生した 1 行以上のコードをマークするコード スニペットが表示されるようになりました。 Azure DevOps リポジトリ内の元のファイルに移動するには、コード スニペットの上にあるファイル名をクリックします。
アラートの概要に表示される切り捨てられたシークレット
検出されたシークレットの最後の 6 文字が、シークレットアラートの概要画面に表示されるようになりました。 この機能は、同じ種類のシークレットが複数公開されている場合に役立ちます。これにより、特定のシークレットが存在する場所をすばやく特定できます。
コード スキャン アラートに追加されたアラートの重大度の追加
CodeQL quality
クエリのアラート結果に対して、新しいアラートの重大度が 、Warning
、重大度Note
としてError
存在するようになりました。 品質アラートの重大度にはそれぞれ、スケーリングの重大度を示す独自のバッジと色があります。 セキュリティ アラートの重大度スケールと同様にlow
critical
、これらの重大度ごとにフィルター処理することもできます。
GitHub Advanced Security for Azure DevOps の有効化に必要なリンクされた Azure サブスクリプション
リンクされた Azure サブスクリプションを持たない Azure DevOps 組織のリポジトリに対して Advanced Security を以前に有効にしていた場合、Advanced Security がそれらのリポジトリで自動的に無効になっていることがわかります。 Advanced Security を再度有効にするには、関連付けられている Azure サブスクリプションを組織に追加します。 サブスクリプションを追加または変更する方法の詳細については、「Azure サブスクリプションの変更」を参照してください。
高度なセキュリティ API の更新
最近出荷された Advanced Security API のさまざまな更新プログラム:
- GET Alerts API では、アラートの増分リストを返し、
ModifiedSince
この日付以降に変更されたアラートのみを返す新しいパラメーターがサポートされるようになりました。 詳細については、「アラート - 一覧」を参照してください。 - 組織またはプロジェクトの高度なセキュリティ有効化状態をフェッチまたは更新するための新しいエンドポイントが 2 つあります。 どちらのエンドポイントも、Advanced Security が有効になっているリポジトリの一覧を返します。 詳細については、「組織 - 有効化」または「プロジェクト - 有効化」を参照してください。
- 組織またはプロジェクトのアクティブなコミッター数の見積もりをフェッチして、高度なセキュリティメーターの推定使用量を反映する新しいエンドポイントが 2 つあります。 詳細については、「組織メーターの使用量の見積もり」または「プロジェクトメーターの使用量の見積もり」を参照してください。
セキュリティの高度なアクセス許可が完全に表示されるようになりました
以前は、Advanced Security が有効になっている場合、3 つの Advanced Security アクセス許可ビットはリポジトリごとの割り当て可能なアクセス許可としてのみ存在していました。 これで、これらのアクセス許可は既定で [リポジトリ > セキュリティのアクセス許可] ウィンドウで使用でき、Advanced Security を有効にしなくても割り当てることができます。
Azure Boards
GitHub コミットまたはプル要求へのリンクを追加する (プレビュー)
作業項目を GitHub のプル要求またはコミットに接続するには、2 つのオプションがあります。 プル要求で AB# 構文を使用することも、作業項目から直接リンクすることもできます。 現在、このプロセスでは、GitHub pull request の URL をコピーし、リンクを追加するときに貼り付ける必要があります。 これには、複数のウィンドウを開き、GitHub と Azure DevOps を切り替える必要があります。
このスプリントでは、GitHub プル要求またはコミットにリンクするときに検索機能を有効にすることで、エクスペリエンスが強化されたことをお知らせします。 目的のリポジトリを検索して選択し、ドリルダウンして特定のプル要求またはコミットを見つけてリンクします。 複数のウィンドウの変更やコピー/貼り付けを行う必要はありません (ただし、そのオプションはまだあります)。
Note
この機能は、新しい Boards Hub プレビューでのみ使用できます。
この機能へのアクセスに関心がある場合は、組織名 (dev.azure.com/{組織名}) と共に直接メールをお送りください。
新しい Boards Hub の機能強化
このリリースでは、アクセシビリティとページリフローに重点を置いて、New Boards Hub プレビューにさまざまな機能強化を導入しました。
最大 400% のズームに適応するページ リフローの変更の例を次に示します。
さらに、作業項目のフォーム、ボード、バックログの各ページでパフォーマンスの向上をロールアウトしました。 これらの変更により、新しいボードは、古いボードで設定されたパフォーマンス標準に一致することが期待できます。
開発と展開の制御
プロジェクトの構成方法に応じて、作業項目から開発コントロールまたは配置コントロールを削除します。 たとえば、リポジトリやパイプラインをオフにするようにプロジェクト設定を構成できます。
作業項目に移動すると、対応する開発コントロールと配置コントロールがフォームに表示されなくなります。
GitHub リポジトリを Azure Boards に接続する場合は、GitHub リポジトリの開発コントロールが表示されます。
Azure Pipelines
Azure Resource Manager サービス接続のワークロード ID フェデレーションが一般公開されました
9 月に、 シークレットを使用せずに Azure サービス接続を構成する機能を発表しました 。 それ以来、多くのお客様がこの機能を採用しており、この機能が一般公開されたことをお知らせします。
ワークロード ID フェデレーションをまだ使用していない場合は、次の方法で、期限切れのシークレットがない心配のない Azure サービス接続を利用できます。
ワークロード ID フェデレーションを使用して新しい Azure サービス接続を作成するには、Azure サービス接続作成エクスペリエンスでワークロード 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 エージェントによるメモリとディスク領域の使用状況を追跡する機能が追加されました。
お客様が認識できるように、エージェントのメモリやディスク領域の制限などのリソース制約がある可能性があるため、リソースの制約がより見えやすくなっています。
上記のメッセージのいずれかが表示された場合、これは、エージェントがディメンション化されているよりも多くのリソースを使用しているタスクが原因で発生する可能性があります。その結果、エージェントが応答せず、パイプライン ジョブが失敗する可能性があります。
「エージェントからの聞き取りを停止しました」
このような場合は、詳細ログを有効にして、より詳細なリソース使用率メッセージを取得し、エージェントがリソースを使い果たした場所を追跡します。 セルフホステッド エージェントを使用している場合は、エージェントに十分なリソースがあることを確認します。
ノード 6 タスク ランナーの帯域外インストール
Azure Pipelines には、次の 2 つのバージョンのエージェント パッケージが用意されています。
- vsts-agent-* パッケージは、Node 6 を使用して実行するタスクをサポートします。
- pipelines-agent-* パッケージは、Node 6 の実行を必要とするタスクをサポートしていません。
セルフホステッド エージェントを作成するお客様は、パイプライン エージェント のリリース ページからこれらをダウンロードできます。 エージェントに含まれる Node バージョンは、タスクの実行に使用されます。 ノード ランナーのバージョンを参照してください。
エージェントの登録後、pipelines-agent-* パッケージからインストールされたエージェントは、エージェントに含まれていないノード バージョンをダウンロードし、組織の設定の [タスクの制限] でブロックされなくなります。 これにより、お客様は pipelines-agent-* エージェント パッケージを使用し、組織の設定で "タスク制限" を使用して Node 6 のインストールを制御できます。
遅延承認
承認を使用して、デプロイでサインオフできます。 ただし、承認が与えられ、デプロイを開始する時刻が一致しない場合があります。 たとえば、確認する特定のデプロイでは、それが範囲外であることがわかります。 それはすぐに進むのではなく、夜の間に行われるべきであると想像してください。
このようなシナリオに対応するために、YAML パイプラインの承認を延期するオプションを追加しました。 これで、パイプラインの実行を承認し、承認を有効にするタイミングを指定できます。
[承認の延期] を選択 すると、承認が有効になる時間を構成できます。
承認は、チェックパネルに遅延として表示されます。 遅延時間が経過すると、承認が有効になります。
承認とチェックのシーケンス処理
このスプリントを使用すると、承認とチェックの実行順序を指定できます。
承認とチェックを使用すると、運用環境へのデプロイを制御できます。 たとえば、リポジトリのブランチで main
実行されるパイプラインのみが運用 ARM サービス接続の使用を許可されるように指定できます。 さらに、人間の承認を要求し、システムがパフォーマンスチェックを渡す必要があります。
現在まで、排他ロックを除き、すべての承認とチェックが並列で実行されました。 つまり、手動承認が与えられる前に、デプロイ プロセスでパフォーマンスチェックが成功する必要がある場合は、Azure Pipelines でこれを適用できませんでした。 承認の指示と内部プロセスのドキュメントに依存する必要がありました。
このスプリントでは、承認とチェックのシーケンス処理を導入しています。 承認とチェックには、次の 5 つのカテゴリがあります。
- 静的チェック:分岐制御、必要なテンプレートと評価アーティファクト
- 動的事前チェック承認
- ダイナミックチェック:承認、Azure関数の呼び出し、REST APIの呼び出し、営業時間、Azure Monitorアラートの照会
- 動的チェック承認後
- 排他ロック
順序は、[承認] タブと [チェック] タブにも表示されます。
各カテゴリ内では、チェックが並列で実行されます。 つまり、Azure 関数の呼び出しチェックと営業時間チェックがある場合は、同時に実行されます。
カテゴリを 1 つずつ実行し、失敗した場合、残りのチェックは実行されません。 つまり、ブランチ コントロールがチェックされ、承認がある場合、Branch コントロールが失敗した場合、承認も失敗します。 そのため、不要なメールは送信されません。
動的チェックが実行された後、動的チェック承認後にデプロイにサインオフするか、動的チェックに進む前に手動検証を実行して、事前動的チェック承認を使用できます。
YAML パイプラインの編集時に既定で検証と保存を行う
YAML パイプラインが正しくないと、時間と労力が無駄になる可能性があります。 パイプライン編集の生産性を向上させるために、エディターの [保存] ボタンを変更して、YAML 検証も行います。
パイプラインにエラーがある場合でも、それを保存できます。
また、検証エクスペリエンスも改善され、理解しやすい一覧にエラーが表示されます。
Azure Repos
承認されていないユーザーがビルド ポリシーとしてパイプラインを構成するための防止
承認されていないユーザーがビルド ポリシーとしてパイプラインを構成するための防止
以前は、新しいビルド ポリシーを追加しているときに、ドロップダウン リストから任意のパイプラインを実行するように構成できました (キュー ビルドのアクセス許可がないパイプラインを含む)。 同様に、キュー ビルドのアクセス許可がない パイプラインを実行するように構成されている場合でも、既存のビルド ポリシーを 編集できます。
これで、ユーザーがこれを行うのを防ぎます。 ユーザーが特定のパイプラインのビルドアクセス許可をキューに拒否された場合、そのパイプラインは、新しいビルド ポリシーを追加するときにドロップダウンに無効 (灰色表示) として表示されます。
キュー ビルドのアクセス許可が拒否されている "Sandbox" という名前のパイプラインを示す下の画像を参照してください。
キュー ビルドのアクセス許可が拒否されたユーザーが新しいビルド ポリシーを追加しようとしている場合に、ドロップダウンで "Sandbox" が無効 (グレー表示) されたパイプラインを示す下の画像を参照してください。
"Sandbox" という名前のパイプラインを実行するように構成されたビルド ポリシーが既に存在する場合、キュー ビルドアクセス許可を持たないユーザーは、ビルド ポリシーを編集または表示できません。 このケースを次の図に示します。
ユーザーがこのようなポリシーを削除しようとすると、削除の確認を求めるポップアップ ダイアログが表示されます。
これらの変更は、ビルド ポリシーの作成または編集を行う API 呼び出しにも適用されます。 キュー ビルドのアクセス許可のないユーザー ID を使用してこれらのアクションを実行すると、呼び出しは失敗し、適切なエラー コードと、このアクションを実行するには、このパイプラインに対する QueueBuild アクセス許可が必要であることを示す“TFS.WebApi.Exception: TF401027:
エラー メッセージが返されます。" というメッセージが表示されます。
キュー のないビルドアクセス許可を使用して user identity
API 経由で 実行されたビルド ポリシーの削除は成功し、警告や防止は行われません (API による削除のしくみに変更はありません)。
Azure Artifacts
Rust クレートのサポートが一般公開されました
2024 年 2 月 16 日から、Rust Crates のサポートは Azure Artifacts で一般公開される機能になります。 課金メーターは、サポートされている他のプロトコルに適用されるのと同じ価格モデルを使用してアクティブ化されます。
npm 監査に対する Azure Artifacts のサポート
Azure Artifacts でサポートとnpm audit fix
コマンドがnpm audit
サポートされるようになりました。 この機能を使用すると、ユーザーは安全でないパッケージバージョンを自動的に更新することで、プロジェクトの脆弱性を分析して修正できます。 詳細については、 npm 監査を使用してパッケージの脆弱性を検出して修正します。
次のステップ
Note
これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。
Azure DevOps に向かい、見てみましょう。
フィードバックの提供方法
これらの機能に関するご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。
Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。
よろしくお願いします。
Dan Hellem