Azure PipelinesのWorkload identityフェデレーションがパブリックプレビューになったことをお知らせします！Azure (ARM) サービス接続は、Workload identityフェデレーションをサポートするスキームを追加しました。
パブリックプレビューにサインアップする方法については、リリースノートをご覧ください。
- Azure PipelinesでWorkload identityフェデレーションをサポートします (public preview)
- Pipelineエージェント登録時PATの代わりにAzure Active Directoryの認証機能が使用可能になりました
- Environments用のREST APIドキュメントを公開しました
- 意図しないパイプラインの実行が防止されます
- GitHubからforkしたレポジトリのビルド設定をデフォルトでセキュア状態にします
- ビルドが失敗した場合、コードカバレッジポリシーのステータスを'Failed'で上書きする機能を無効にしました
制限は、大規模でグローバルなサービスの健全性と効率性を維持する上で重要な役割を果たします。このスプリントでは、area pathとiteration pathの両方に、プロジェクトあたり10,000のハードリミットを導入します。Work tracking, process, project limitのページで、サービス内のさまざまな制限について確認してください。
Azureサービス接続にシークレットと証明書を保存するのをやめたいですか？これらのシークレットが期限切れになるたびにローテーションする心配をしたいですか？Workload identityフェデレーションは、業界標準の技術であるOpen ID Connect（OIDC）を使用して、Azure PipelinesとAzure間の認証を簡素化します。シークレットの代わりに、フェデレーション・サブジェクトがこの認証を容易にしてくれます。
この機能の一環として、Azure (ARM) サービス接続は、Workload identityフェデレーションをサポートする別のスキームに更新されました。これにより、Azure サービス接続を使用する Pipeline タスクは、フェデレーション サブジェクト（sc://<org>/<project>/<service connection name>）を使用して認証できるようになります。既存の認証スキームと比較して、このスキームを使用する主な利点は次のとおりです。
- 管理の簡素化： Azure ADのサービスプリンシパルからAzure DevOpsへのシークレットの生成、コピー、保存が不要になります。Azureサービス接続の他の認証スキーム（サービスプリンシパルなど）で使用されるシークレットは、一定期間（現在は2年）が経過すると失効します。有効期限が切れると、パイプラインが失敗します。新しいシークレットを再生成し、サービス接続を更新する必要があります。Workload identityフェデレーションに切り替えると、これらのシークレットを管理する必要がなくなり、サービス接続の作成と管理の全体的なエクスペリエンスが向上します。
- セキュリティの向上： Workload identityフェデレーションでは、Azure PipelinesとAzure間の通信に永続的なシークレットが関与しません。その結果、パイプラインジョブで実行されるタスクから、本番環境にアクセスできるシークレットが漏れたり、流出したりすることはありません。これは、お客様にとってしばしば懸念事項でした。
これらの機能は、2つの方法で利用できます。
- 新しい Azure サービス接続を作成するときは常に、新しいWorkload identity連携スキームを使用します。今後、これが推奨されるメカニズムになります。
- （シークレットに基づいている）既存のAzureサービス接続を新しいスキームに変換します。この変換は、一度に1接続ずつ実行できます。何より、これらのサービス接続を使用するパイプラインを変更する必要はありません。変換が完了すると、新しいスキームが自動的に適用されます。
Workload identityフェデレーションを使用して新しい Azure サービス接続を作成するには、Azure サービス接続作成エクスペリエンスでWorkload identityフェデレーション（automatic）または（manual）を選択します。
以前に作成したAzureサービス接続を変換するには、接続を選択した後に "Convert"アクションを選択します。
Azure Pipelinesに含まれるすべてのAzureタスクが、この新しいスキームをサポートするように更新されています。ただし、Marketplaceのタスクや自作のカスタムタスクをAzureにデプロイするために使用している場合、Workload identity連携をまだサポートしていない可能性があります。このような場合は、セキュリティを向上させるために、Workload identityフェデレーションをサポートするようにタスクを更新してください。サポートされるタスクの完全なリストは、こちらを参照してください。
このプレビューでは、Azure サービス接続に対してのみWorkload identityフェデレーションをサポートします。このスキームは、他のタイプのサービス接続では機能しません。詳細はドキュメントをご覧ください。
このブログ記事にも詳細が記載されています。
Pipelineエージェントが、エージェントの登録にService Principalまたはユーザを使用する引数をサポートするようになりました。セキュリティ設定で、エージェントプールへのアクセス権を付与する必要があります。これにより、エージェントの1回限りのセットアップに Personal Access Token (PAT) を使用する必要がなくなります。
Service Principal を使用して Azure DevOps Services に Pipelines エージェントを登録するには、以下の引数を指定します。
--auth 'SP' --clientid 12345678-1234-1234-abcd-1234567890ab --clientsecret --tenantid 12345678-1234-1234-abcd-1234567890abAzure VMでは、VM Extensionを使用してDeployment Groupsに含めることができます。VM Extensionはエージェントの登録にPATではなく Service Principal を使用するように更新されました。
"settings": {
"userServicePrincipal": true
}
"protectedSettings": {
"clientId": "[parameters('clientId')]"
"clientSecret": "[parameters('clientSecret')]"
"tenantId": "[parameters('tenantId')]"
}ウェブブラウザで簡単にセットアップが完了します。エージェント設定スクリプトを実行する際、認証タイプに "AAD"と入力します。スクリプトは、ウェブ上のどこに行くか、どのコードを入力するかなど、次のステップを案内します。ウェブ上でコードを入力した後、コンソールに戻ってエージェントの設定を完了します。
Environmentとは、パイプラインからのデプロイでターゲットにできるリソースのコレクションです。Environmentsには、デプロイ履歴、作業項目とコミットのトレーサビリティ、アクセス制御メカニズムを提供します。
プログラムでEnvironmentを作成したいという要望は理解できるので、REST APIのドキュメントを公開しました。
現時点において、YAMLパイプライン内でtriggerセクションが存在しない場合、リポジトリにプッシュされたすべての変更が検知され、パイプラインが実行されます。これはなぜパイプラインが実行されたのか混乱させ、多くの意図しない実行につながります。
この挙動を変更できるように、Disable implied YAML CI triggerというorganizationレベルとProjectレベルのパイプライン設定を追加しました。パイプラインのトリガーセクションがない場合、パイプラインがトリガーされないように指定できます。
前回のスプリントでは、フォークしたGitHubリポジトリからPRをビルドするための集中管理機能を紹介しました。
今回のスプリントでは、新しいorganizationに対して、Securely build pull requests from forked repositories(フォークしたリポジトリからのpull requestを安全にビルドする)オプションをorganizationレベルで有効にします。既存のorganizationでは影響を受けません。
以前は、PRでのビルドが失敗した場合、コードカバレッジポリシーのステータスが'Failed'で上書きされていました。これは、ビルドをオプションのチェックとし、コードカバレッジポリシーをPRの必須チェックとしていた一部の人にとって、PRがブロックされる原因となっていました。
このスプリントにおける改善で、ビルドが失敗してもコードカバレッジポリシーが'Failed'で上書きされません。この機能はすべての顧客に対して有効になります。
Azure DevOpsはクローン/フェッチ中に2つの追加フィルタリングをサポートするようになりました。--filter:blob=noneと--filter:tree:0というオプションです。最初のオプション（blobless clone）は通常の開発に最適で、2番目のオプション（treeeless clone）は、例えばビルドを実行した後、クローンを破棄する場合に適しています。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
Azure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Silviu Andrica