OpenID Connect で GitHub Actions から Azure に認証する方法

OpenID Connect で実現する、セキュアな CI/CD

CI/CD ワークフローは、現代のソフトウェア開発において不可欠な要素となり、ソフトウェアデリバリーのスピードと信頼性を劇的に向上させています。振り返ってみると、スプレッドシートのリリースチェックリストに従い、Azure ポータルで手動でボタンをクリックしてアプリケーションをデプロイしていた時代が、どうやって成り立っていたのか想像もつきません。

最近、サービスプリンシパルのシークレットを使用する以外の、GitHub Actions から Azure への認証方法を検討しています。期待通りに動作する一方で、シークレットの管理はワークフローのオーバーヘッドを増やし、特にセキュリティチームがシークレットの使用状況の詳細を要求する際には、その負担はさらに大きくなります。本記事では、OpenID Connect (OIDC) を使用することでこのプロセスをどのように効率化できるかを探ります。これにより、機密性の高い Azure シークレットを GitHub に保存する必要がなくなるだけでなく、サービスプリンシパルの使用状況に対する可視性も同時に高まります。

GitHub Actions 向け Microsoft Entra ID の設定

GitHub Actions ワークフローが Azure リソースにアクセスできるようにするには、まず Azure テナントにアプリケーションを登録し、信頼関係を確立する必要があります。このプロセスにより、アプリケーションオブジェクトと、対応するサービスプリンシパルオブジェクトの両方がテナント内に作成されます。当初、私はアプリケーションオブジェクトとサービスプリンシパルの違いについて混乱していましたが、少し調べた結果、ようやくその違いが明確になりました。

• アプリケーションオブジェクトは、アプリケーションのグローバルな設計図（ブループリント）として機能し、最初に登録されたテナントに存在します

• 一方、サービスプリンシパルは、そのアプリケーションが利用される任意のテナントで、アプリケーションオブジェクトからインスタンス化されるローカルな表現です

このシナリオでは、アプリケーションが我々のテナントに登録されると、アプリケーションオブジェクトは本質的にそこに存在します。アプリケーションがアクティブかつ利用可能になるためには、このアプリケーションオブジェクトに基づいて、我々のテナント内に対応するサービスプリンシパルが作成されます。しかし、重要な違いは、他のテナントが我々のアプリケーションを利用する場合に生じます。そのような場合、我々の単一のアプリケーションオブジェクトから派生した追加のサービスプリンシパルが、それぞれのテナントに作成されます。この設計により、管理者は、各サービスプリンシパルに対して、そのテナント内で直接、きめ細かく適切な権限を割り当てることが保証されます。

OpenID Connect (OIDC) 用フェデレーテッド資格情報の作成

アプリケーションの登録後、次のステップは、サービスプリンシパルにフェデレーテッド資格情報を作成することです。クライアントシークレットや証明書といった他の認証オプションも存在しますが、これらにはいくつかのセキュリティと管理の課題が伴います。

• シークレットや証明書を GitHub に保存する必要がある
• セキュリティを維持するために手動でのローテーションが求められる
• 長期間有効な資格情報はセキュリティリスクを高める
• きめ細かさに欠けるアクセス制御

これらの懸念を踏まえると、OpenID Connect (OIDC) は、より安全で保守性の高いソリューションを提供します。OIDC は、シークレットを保存する必要がなく、短期間のみ有効なトークンをサポートし、より優れた追跡可能性を提供するため、GitHub Actions から Azure への認証において強力な選択肢となります。

さらに、フェデレーテッド資格情報を設定する際には、特定の GitHub ワークフローに対応するサブジェクト識別子を定義できます。この識別子には、組織、リポジトリ、そしてブランチ、環境、プルリクエスト、タグなどのエンティティタイプを含めることができます。このようにきめ細かな設定が可能になることで、サービスプリンシパルへのアクセスを制限し、特定のサブジェクト識別子を持つ指定されたワークフローのみが Azure リソースとやり取りできるようになります。

サービスプリンシパルへの権限の定義

サービスプリンシパルの作成後、次のステップは適切なロールを割り当てることです。多くの場合、Contributor ロールは基本的な選択肢となります。これは、ロールや権限の変更はできないものの、Azure リソースの作成と管理の権限を付与するためです。しかし、セキュリティを強化するためには、以下のベストプラクティスを考慮してください。

• スコープの最小化：Contributor ロールは、サブスクリプションや管理グループレベルではなく、リソースグループレベルで割り当てます。これにより、サービスプリンシパルのアクセスが、管理すべきリソースのみに限定されます

• ポリシーの強制：Azure Policy を使用してガバナンスを強制し、過度なリソース利用を防ぎます。たとえば、サブスクリプション内でデプロイできるリソースの種類を制限できます

• カスタムロールによる最小権限の原則：可能な限り、タスクに必要な特定の権限のみを付与するカスタムロールを定義します。このアプローチは設計と維持に手間がかかりますが、攻撃対象領域を大幅に縮小します

GitHub Actions での Azure 識別子の安全な管理

OpenID Connect (OIDC)によって機密性の高い Azure シークレットを GitHub に直接保存する必要はなくなりますが、Azure ログインアクションでは、適切な認証のためにいくつかの重要な詳細情報が依然として必要です。これには以下が含まれます。

• Azure Tenant ID – Microsoft Entra ID テナントを識別します

• Azure Client ID – Azure に登録されたサービスプリンシパルを指します

• Azure Subscription ID – リソースがデプロイされるサブスクリプションを指定します

これらの値は、従来のシークレットや証明書ほど機密性が高いわけではありませんが、引き続き安全に管理することがベストプラクティスです。GitHub Secrets にこれらを保存することで、プレーンテキストで公開することなく、ワークフローに安全に渡すことができます。

セキュリティをさらに強化するためには、GitHub Environments を活用して、デプロイ環境に基づいてこれらのシークレットへのアクセスを制限できます。例えば、本番環境へのデプロイ資格情報を専用の Environment で保護し、明示的なビジネス承認を得たワークフローのみがアクセスできるように設定することが可能です。

Azure でのサービスプリンシパルアクティビティの監視

サービスプリンシパルのアクティビティを効果的に監視するには、Azure に組み込まれているサインインログとアクティビティログを活用できます。これらの非常に価値のあるツールは、フェデレーテッド ID の認証試行と、それが実行した特定のアクションの両方に対する可視性を提供します。よりプロアクティブに対応したい場合は、Azure Monitor を設定してこれらのログからアラートを作成できます。これにより、不審なアクティビティや予期せぬアクセスパターンが検知された際に、迅速に通知を受け取ることが保証されます。

まとめ：エージェントセキュリティの展望

Microsoft Entra ID や OpenID Connect は複雑なテーマですが、今回の調査を通じて理解を深めることができ、非常に有意義でした。特に外部プログラムが利用する ID に関する IAM（アイデンティティおよびアクセス管理）の知識を習得できたことは大きな収穫です。ユーザーに代わってタスクを実行するエージェントアプリケーションが増えていく中で、この知識はますます重要になると感じています。サービスアカウントに対する適切なアクセス制御は、今後間違いなく不可欠なセキュリティ上の考慮事項となるでしょう。次のステップとして、エージェントアプリケーションの学習を開始する際に、エージェント固有のアクセス制御管理について調査を進めていきたいと思います。

お読みいただきありがとうございました。