Azure DevOpsのAzure Pipelinesサービスコネクションの紹介と運用の注意点
こんにちは、NRIデジタルの大場です。
Azure DevOpsの主な機能のひとつであるAzure Pipelinesで「Azure Resource Manager Workload Identity」という認証方式が追加され、サービスコネクションにおける認証管理がシンプルになりました。今までどのような問題があったのか、それをどう解決しているのか、について紹介していきます。
Azure DevOpsとは？
まずは、その機能を紹介する前にAzure DevOps自体についてご紹介します。
Azure DevOpsはソフトウェア開発プロジェクトの計画、開発、配信、運用を支援する一連の開発ツールを提供するMicrosoftのクラウドサービスです。このプラットフォームは、コードの共有、作業の追跡、自動ビルドとデプロイメントのプロセスを統合し、チームがより効率的にソフトウェアを開発、テスト、リリースできるように設計されています。
Azure DevOpsは、多様なプログラミング言語（最近ではAzure ArtifactsでRustCraftも対応されたりしています！）やプラットフォームをサポートし、オープンソースの統合も強化しています。
このAzure DevOpsのなかにAzure Pipelinesがあり、CI/CD（継続的インテグレーション/継続的デリバリー）を実現するためのツールです。自動ビルド、テスト、デプロイメントを実施し、ソフトウェアのリリースプロセスを自動化します。
今回紹介するサービスコネクションというのは、Azure Pipelinesの1機能です。
Azure Pipelinesにおけるサービスコネクション（サービス接続）とは？
Azure Pipelinesのサービスコネクションは、Azure Pipelinesが外部のサービスやリソースに安全に接続するための機構です。これにより、ビルドやリリースプロセス中に外部システム、たとえばソースコードリポジトリ、コンテナレジストリ、クラウドプラットフォーム、その他のサードパーティサービスにアクセスできるようになります。サービスコネクションを使用することで、認証情報を安全に管理し、CI/CDパイプラインの自動化を強化できます。
サービスコネクションで注意すべき点
サービスコネクションは“よしなに”パイプラインにデプロイする対象や関連サービスに接続してくれます。
ただ、Azure Pipelinesのサービスコネクションを設定する際には、いくつかの重要な注意点を理解し、適切な管理を行うことが必要です。サービスコネクションは、外部のサービスやリソースに対する認証情報を保持するため、セキュリティと管理の観点から注意深く扱う必要があります。
- 有効期限の管理：
一部のサービスコネクション（特に、Azureサービスプリンシパルを使用するもの）には有効期限が設定されています。有効期限が切れると、コネクションを介したアクセスが失敗するため、期限前に更新を行う必要があります。 - 権限の最小化：
サービスコネクションを作成する際には、必要最小限の権限を持つ認証情報を使用することが推奨されます。過剰な権限を持たせると、セキュリティリスクが高まります。 - セキュリティの強化：
サービスコネクションのセキュリティを確保するため、定期的なパスワードや秘密鍵の変更、複雑なパスワードポリシーの適用、監査ログの確認などが重要です。 - 適切な権限レベルのアカウント使用：
サービスコネクションの作成と管理には、対象サービスやリソースで適切な権限を持つアカウントが必要です。たとえば、Azureサービスに接続するためには、Azureサブスクリプションの管理者権限が必要になる場合があります。 - アクセス制御の設定：
Azure DevOps内でサービスコネクションへのアクセスを制限することが可能です。不必要なユーザーやグループにはアクセス権を付与しないようにしましょう。
上記の中で、特に運用上気を付けないといけないのが①の有効期限と④の作成権限になります。
有効期限に関しては、サービスコネクションを作成すると、作成者の知らぬ間に裏でサービスプリンシパルが作られ、しかも有効期限が2年のため、長期運用していくと知らない間に有効期限が切れて、パイプラインが失敗するということになってしまいます。
また、サービスコネクションは裏でサービスプリンシパルが作られることもあって、Microsoft Entra ID を操作できる強い権限でないといけないこともあり、設定するためには運用フローも検討する必要が出てきます。
個人開発では簡単にできて、非常に便利ですが、大きなシステムの中でやりくりする中では結構大変だったりします（良い機能ではありますが・・・）。
サービスコネクションに新しい認証方式が増えた！
上記のような認証の複雑性の課題を払拭するために、最近、Azure Resource Managerでサービスコネクションの新しい認証方式Azure Resource Manager Workload Identity が増えました。
Manager Workload Identityは、Azureサービスで実行されるアプリケーションやワークロードが、Azure Active Directory (Azure AD) のアイデンティティを使用して他のAzureリソースに安全にアクセスできるようにする機能です。これにより、アプリケーションはサービスプリンシパルや管理IDなどの従来の認証方法に依存することなく、Azure ADのアイデンティティを用いてAzureリソースへのアクセス権を委任・管理できます。
特に運用上楽になるのは、セキュリティが強化され、管理が必要ではなくなることです。
Workload Identityは、アプリケーションがAzureリソースへアクセスする際のセキュリティを強化しながら、認証情報の管理を簡素化します。サービスプリンシパルのシークレット値や証明書のような静的な認証情報を管理する必要がなくなります。（期限管理もいらない！）
実際にAzure DevOpsからやってみましょう。Azure Resource Managerのサービスコネクションの作成画面で、Workload Identity federationという項目が追加されています。Workload Identity federationは2種類あり、推奨されているのはautomaticのほうであり、設定画面から作成することができます。すでに作成済の場合はmanualから設定することが可能です。こちらの設定はほかのサービスコネクションと同様、Azure DevOpsの管理者権限が必要であり、Microsoft Entra ID 権限も強い権限が必要となります。
今回はWorkload Identity federation（automatic）を実際に設定してみたいと思います。
サブスクリプションとリソースグループを選んで、サービスコネクション名を入力して、Saveします。
サービスコネクションが作成できました。ただ、それだけだとどのように作成されたかわからないので、中身を見てみます。
サービスコネクションのDetailsで「Manage Service Principal」という箇所をクリックしてみます。そうすると、Azureポータルにリンクするのですが、AzureポータルはMicrosoft Entra ID 権限がないと参照できません。
運用面の実態として、Azure DevOpsを運用していくメンバーは、Microsoft Entra ID 権限を持たない人が大半だったりすることもあるので、ここで中身を把握・管理するのは大変です。それはWorkload Identity認証であっても同様です。
ちなみに、「Manage service connection roles」をクリックすると、リソースグループのアクセス制御 (IAM)にリンクします。こちらも権限を見る際には確認が必要です。
Microsoft Entra IDのアプリができていることを確認できます。こちらの名称は「Azure DevOpsの組織名-Project名-自動採番」されます。この命名規則はほかのサービスコネクション作成で作られるサービスプリンシパル認証とも同じのようです。
Microsoft Entra ID内では管理すべきだと思うのですが、この名称のつけ方だと、複数のサービスコネクションを作成した場合にわからなくなります。Azure DevOps Pipelinesからリンクで飛べるとはいっても、追跡するのは大変なので、Workload Identity federation（automatic）の方式でサービスコネクションを作成したタイミングで管理台帳等で記載したほうが良いのではないかと思います。
このようなことから、Workload Identity federation（manual）のほうが作成は手間でも運用上の負荷は減るので良いと思いました。
肝心の証明書やシークレットの件ですが、「証明書とシークレット」を選択すると、証明書やクライアントシークレットは作成されておらず、フェデレーション資格情報に記載されていました。
期限付きのシークレットを保持せず、期限管理もしなくて良いのはだいぶ楽にはなります。
必要なくなったサービスコネクションの削除はAzure DevOpsからできます。サービスコネクションに紐づいているMicrosoft Entra IDのアプリも削除されました。
まとめ
サービスコネクション作成は、基本的にWorkload Identity federationを使うのが良いかと思います。
期限付きのシークレットがなくなっただけでも非常に便利であり、しかも、セキュリティ的に各段に上がったWorkload IdentityをAzure DevOpsで使えるのは魅力的です。
ただ、推奨とされているWorkload Identity federation（automatic）は、命名が自動的にされてしまい、後から追いかけるのは難しく、運用上、大規模なシステムや複数のプロダクトを一つのMicrosoft Entra IDのテナント内で行う場合、大変かと思いました。Workload Identity federation（manual）の選択肢も考えても良いかもしれません。
Azure DevOpsは、高機能で開発関連の多岐にわたるサービスであり、UIもフレンドリーで魅力的だと思います。今後もアップデートして、より便利になっていくことを期待しています。