Azure Pipelines - Sprint 227 Update
機能
Azure Pipelines でのワークロード ID フェデレーション (パブリック プレビュー)
Azure サービス接続へのシークレットと証明書の格納を停止しますか? 有効期限が切れるたびにこれらのシークレットのローテーションについて心配するのをやめたいですか? Azure サービス接続のワークロード ID フェデレーションのパブリック プレビューが発表されました。ワークロード ID フェデレーション では、業界標準のテクノロジである Open ID Connect (OIDC) を使用して、Azure Pipelines と Azure の間の認証を簡略化します。 この認証を容易にするため、シークレットの代わりにフェデレーションサブジェクトを使用します。
この機能の一環として、Azure (ARM) サービス接続が、ワークロード ID フェデレーションをサポートする別のスキームで更新されました。 これにより、Azure サービス接続を使用するパイプライン タスクは、フェデレーションサブジェクト (sc://<org>/<project>/<service connection name>) を使用して認証できます。 既存の認証スキームよりもこのスキームを使用するメインの利点は次のとおりです。
- 管理の簡素化: Azure AD のサービス プリンシパルから Azure DevOps にシークレットを生成、コピー、および格納する必要がなくなりました。 Azure サービス接続の他の認証スキーム (サービス プリンシパルなど) で使用されているシークレットは、一定期間 (現在 2 年間) 経過すると期限切れになります。 有効期限が切れると、パイプラインは失敗します。 新しいシークレットを再生成し、サービス接続を更新する必要があります。 ワークロード ID フェデレーションに切り替えると、これらのシークレットを管理する必要がなくなり、サービス接続の作成と管理の全体的なエクスペリエンスが向上します。
- セキュリティの強化: ワークロード ID フェデレーションでは、Azure Pipelines と Azure の間の通信に永続的なシークレットは関係しません。 その結果、パイプライン ジョブで実行されているタスクは、運用環境にアクセスできるシークレットをリークまたは流出させることはありません。 これは多くの場合、お客様にとって懸念事項でした。
これらの機能は、次の 2 つの方法で利用できます。
- 新しい Azure サービス接続を 作成するたびに、新しいワークロード ID フェデレーション スキーム を使用します。 今後は、これが推奨されるメカニズムになります。
- 既存の Azure サービス接続 (シークレットに基づく) を新しいスキームに変換 します。 この変換は、一度に 1 つの接続で実行できます。 何より、これらのサービス接続を使用するパイプラインを変更する必要はありません。 変換が完了すると、新しいスキームが自動的に適用されます。
ワークロード ID フェデレーションを使用して新しい Azure サービス接続を作成するには、Azure サービス接続作成エクスペリエンスでワークロード ID フェデレーション (自動) または (手動) を選択するだけです。
以前に作成した Azure サービス接続を変換するには、接続を選択した後に [変換] アクションを選択します。
Azure Pipelines に含まれるすべての Azure タスクで、この新しいスキームがサポートされるようになりました。 ただし、Marketplace のタスクまたは自宅で成長したカスタム タスクを使用して Azure にデプロイしている場合は、ワークロード ID フェデレーションがまだサポートされていない可能性があります。 このような場合は、セキュリティを向上させるために、ワークロード ID フェデレーションをサポートするようにタスクを更新するようお願いします。 サポートされているタスクの完全な一覧については、 こちらをご覧ください。
このプレビューでは、Azure サービス接続に対してのみワークロード ID フェデレーションがサポートされます。 このスキームは、他の種類のサービス接続では機能しません。 詳細については、ドキュメントを参照してください。
このブログの投稿 には、詳細が含まれています。
パイプライン エージェントは、PAT ではなく Microsoft Entra ID を使用して登録できます
パイプライン エージェントでは、サービス プリンシパルまたはユーザーを使用してエージェントを登録するためのより多くの引数がサポートされるようになりました。 セキュリティ設定で、エージェント プールへのアクセス権を使用する ID に付与する必要があります。 これにより、エージェントの 1 回限りのセットアップに個人用アクセス トークン (PAT) を使用する必要がなくなります。
サービス プリンシパルを使用してエージェントを登録する
サービス プリンシパルを使用して Azure DevOps Services に Pipelines エージェントを登録するには、次の引数を指定します。
--auth 'SP' --clientid 12345678-1234-1234-abcd-1234567890ab --clientsecret --tenantid 12345678-1234-1234-abcd-1234567890ab
エージェント VM 拡張機能でサービス プリンシパルを使用する
Azure VM は、VM 拡張機能を使用してデプロイ グループに含めることができます。 VM 拡張機能は、PAT ではなくサービス プリンシパルを使用してエージェントを登録するように更新されました。
"settings": {
"userServicePrincipal": true
}
"protectedSettings": {
"clientId": "[parameters('clientId')]"
"clientSecret": "[parameters('clientSecret')]"
"tenantId": "[parameters('tenantId')]"
}
デバイス コード フローを使用してエージェントを対話形式で登録する
Web ブラウザーを使用すると、簡単にセットアップを完了できます。 エージェント構成スクリプトを実行するときに、認証の種類として「AAD」と入力します。 このスクリプトでは、Web 上の場所や入力するコードなど、次の手順について説明します。 Web でコードを入力したら、コンソールに戻ってエージェントの設定を完了します。
環境用の REST API
環境は、パイプラインからのデプロイでターゲットにできるリソースのコレクションです。 環境には、展開履歴、作業項目とコミットの追跡可能性、アクセス制御メカニズムが用意されています。
プログラムを使用して環境を作成する必要があることがわかっているため、REST API のドキュメントを公開しました。
意図しないパイプラインの実行を防ぐ
現在、YAML パイプラインでセクションが指定 trigger されていない場合は、リポジトリにプッシュされた変更に対して実行されます。 これにより、パイプラインが実行された理由が混乱し、意図しない実行が多数発生する可能性があります。
この動作を変更できる、暗黙的な YAML CI トリガーを無効にするという名前の組織レベルおよびプロジェクト レベルのパイプライン設定を追加しました。 トリガー セクションがない場合は、パイプラインをトリガーしないことを選択できます。
GitHub リポジトリを既定で安全にビルドする
最後のスプリントでは、フォークされた GitHub リポジトリから PR を構築するための一元的なコントロールが導入 されました。
このスプリントを使用して、新しい組織の組織レベルでオプションを有効に Securely build pull requests from forked repositories しています。 既存の組織は影響を受けません。
ビルドが失敗したときにコード カバレッジ ポリシーの状態が [失敗] に無効にされたオーバーライド
以前は、PR のビルドが失敗した場合、コード カバレッジ ポリシーの状態は "Failed" にオーバーライドされていました。 これは、ビルドをオプションのチェックとして持ち、PR に必要なチェックとしてコード カバレッジ ポリシーを使用した場合、PR がブロックされる一部のユーザーにとって阻害要因でした。
このスプリントでは、ビルドが失敗した場合、コード カバレッジ ポリシーは "Failed" にオーバーライドされません。 この機能は、すべての顧客に対して有効になります。
次のステップ
Note
これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。
Azure DevOps に向かい、見てみましょう。
フィードバックの提供方法
これらの機能に関するご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。
Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示