Advanced Security の依存関係スキャンは、ソースコードで使用されているオープンソースコンポーネントを検出し、関連する脆弱性があるかどうかを特定します。オープンソースコンポーネントから検出された脆弱性は、アラートとしてフラグ付けされます。この更新により、Advanced Security の依存関係スキャン アラートで、誤検出または許容できるリスクと思われるアラートを解除できます。
Azure Repos では、新しいブランチを作成するときに"Edit Policy"権限を削除するようにデフォルトの動作を変更しました。
これらの機能の詳細については、リリースノートをご覧ください。
- Kubernetesタスクがkubeloginをサポートします
- Agent VM拡張機能でサービスプリンシパルがつかえるようになります
- YAML cronスケジュール機能について更新しました
- チェックを一時的に無効化できるようになります
- Approvals REST APIの改善を行いました
Azure DevOps OAuthシークレットは、5年ごとに失効するように設定されています。現時点では、お客様が自分でこれらのシークレットをローテーションするためのセルフサービスの方法はありません。これらのシークレットをさらに5年間延長したい場合は、サポートに連絡することをお勧めします。これらのシークレットライフタイムの長さと、これらのシークレット拡張が必要とされる頻度を考慮し、当面の間、すべての Azure DevOps OAuthアプリのシークレット有効期限チェックを解除することにしました。
よりセキュアなシークレットコントロールを必要とするすべてのアプリは、Microsoft Identityプラットフォーム、別名Azure Active Directory OAuthアプリを使用することをお勧めします。Azure AD OAuthアプリは、Azure DevOps REST APIへのアクセスをサポートしています。
誤検出または許容可能なリスクと思われる依存スキャンアラートを解除できるようになりました。これらは、現在使用できる Advanced Security のシークレットスキャンおよびコードスキャンアラートの解除オプションと同じです。
これらのアラートを解除するには、Advanced Security: dismiss alerts権限があるユーザーで依存関係スキャン タスクで検出パイプラインを再実行する必要があることに注意してください。
警告の解除の詳細については、依存関係スキャン警告の解除 を参照してください。
Azure BoardsのいくつかのエリアからワークアイテムのURLをコピーする機能に対して小さな改善を行いました。特定のワークアイテムへの直接リンクを取得しやすくなりました。
ワークアイテムフォーム、バックログ、タスクバックログのコンテキストメニューにCopy Linkボタンが追加されました。
注意事項
この機能は新しいボードハブプレビューでのみ利用可能です。
KuberentesManifest@1、HelmDeploy@0、Kubernetes@1、および AzureFunctionOnKubernetes@1 タスクを更新し、kubelogin をサポートしました。これにより、Azure Active Directory統合で構成されたAzure Kubernetes Service（AKS）をターゲットにできます。
KubeloginはHostedイメージにはプリインストールされていません。上記のタスクがkubeloginを使用するようにするには、それに依存するタスクの前にKubeloginInstaller@0タスクを挿入してインストールします。
- task: KubeloginInstaller@0
- task: HelmDeploy@0
# arguments do not need to be modified to use kubeloginAzureのVMは、VM拡張機能を使用してデプロイメントグループに追加できます。VM拡張機能が更新され、エージェントの登録に PAT の代わりに Service Principal が使えるようになりました。
"settings": {
"userServicePrincipal": true
}
"protectedSettings": {
"clientId": "<clientId>",
"clientSecret": "<clientSecret>",
"tenantId": "<tenantId>"
}Approvals (承認) は本番環境へのデプロイを手動でレビューする可能性を提供することで YAML パイプラインのセキュリティを向上させます。より強力にするために、Approvals Query REST APIを更新しました。これで以下のことが可能になります。
approvalIdのリストを指定する必要がなくなりました。すべてのパラメータがオプションになりました。userIdのリストを指定して、そのユーザーが保留中の承認のリストを取得できます。現在、REST API は、ユーザーが承認者として明示的に割り当てられている承認のリストを返します。- 返される承認の
state(状態) (pendingなど) が取得できます。
以下はその例です： GET https://dev.azure.com/fabrikamfiber/fabrikam-chat/_apis/pipelines/approvals?api-version=7.1-preview.1&userId=47acd774-9773-6c31-bbb6-5a0585695d19&state=pending
{
"count": 2,
"value":
[
{
"id": "87436c03-69a3-42c7-b5c2-6abfe049ee4c",
"steps": [],
"status": "pending",
"createdOn": "2023-06-27T13:58:07.417Z",
"lastModifiedOn": "2023-06-27T13:58:07.4164237Z",
"executionOrder": "anyOrder",
"minRequiredApprovers": 1,
"blockedApprovers": [],
"_links":
{
"self":
{
"href": "https://dev.azure.com/fabrikamfiber/fabricam-chat/_apis/pipelines/approvals/87436c03-69a3-42c7-b5c2-6abfe049ee4c"
}
}
},
{
"id": "2549baca-104c-4a6f-b05f-bdc4065a53b7",
"steps": [],
"status": "pending",
"createdOn": "2023-06-27T13:58:07.417Z",
"lastModifiedOn": "2023-06-27T13:58:07.4164237Z",
"executionOrder": "anyOrder",
"minRequiredApprovers": 1,
"blockedApprovers": [],
"_links":
{
"self":
{
"href": "https://dev.azure.com/fabrikamfiber/fabricam-chat/_apis/pipelines/approvals/2549baca-104c-4a6f-b05f-bdc4065a53b7"
}
}
}
]
}チェックのデバッグがより簡単になりました。Invoke Azure FunctionやInvoke REST APIチェックが正しく動作しないことがあった場合、修正しなくてはなりません。以前は、そのようなチェックが誤ってデプロイをブロックしないように、削除する必要がありました。いったんチェックを修正したら、それを再び追加して正しく設定し、必要なヘッダーがすべて設定されているか、クエリーパラメーターが正しいかを確認する必要があり、非常に面倒なものでした。
今回の更新で、チェックを無効にするだけになりました。無効にしたチェックは、その後のチェック・スイートの評価では実行されなくなります。
誤ったチェックを修正後、有効にしてください。
YAML パイプラインでは、cron YAML プロパティを使ってスケジュールされたトリガーの定義ができます。
batchプロパティがどのように機能するか以下にまとめてみました。簡単に言うと、batchをtrueに設定すると、他のスケジュールされたパイプラインの実行が進行中の場合、cronスケジュールは実行されません。これはパイプラインリポジトリのバージョンとは無関係です。
次の表でalwaysとbatchの相互作用について説明します。
| Always | Batch | Behavior |
|---|---|---|
false |
false |
パイプラインは、最後にスケジュールされたパイプラインの実行が成功した時点から変更があった場合にのみ実行される。 |
false |
true |
最後にスケジュールされたパイプラインの実行が成功し、進行中のパイプラインの実行がない場合にのみ、パイプラインが実行される。 |
true |
false |
パイプラインはcronスケジュールに従って実行される。 |
true |
true |
パイプラインはcronスケジュールに従って実行される。 |
例えば、always: false、batch: trueと設定されたパイプラインを5分ごとに実行するcronスケジュールがあるとします。新しいコミットがあったとします。5分以内にパイプラインはスケジュールされた実行を開始します。パイプラインの実行が完了するまでに30分かかるとします。この30分間は、コミットの数に関係なく、スケジュールされた実行は行われません。次のスケジュールされた実行は現在のスケジュールされた実行が終了した後にのみ行われます。
YAMLパイプラインは複数のcronスケジュールを含むことができ、どのcronスケジュールが実行されるかに基づいてパイプラインに異なるstage/jobを実行させたい場合があります。例えば、ナイトリービルドとウィークリービルドがあり、ウィークリービルド中にパイプラインがより多くの統計情報を収集したいとします。
この要件を満たすためにcronスケジュールのdisplayNameプロパティが新しい定義済みシステム変数Build.CronSchedule.DisplayNameに含まれています。
これまでは、新しいブランチを作成すると、そのブランチのポリシーを編集する権限が付与されていました。今回の更新では、リポジトリの"Permission management"設定がオンになっていても、この権限を与えないようにデフォルトの挙動を変更します。
セキュリティ権限の継承またはグループメンバーシップによって明示的に（手動またはREST APIを通じて）付与された"Edit policies"権限が必要です。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
Azure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Silviu Andrica