跳到主要内容

Service PrincipalとFederated Identity Credential

Azure (Microsoft Entra ID) におけるアプリケーションの認証・認可の仕組みは、セキュリティを維持しながら自動化を実現するために非常に重要です。本ドキュメントでは、Service Principal (サービスプリンシパル) の基本概念と、よりセキュアな認証方式である Federated Identity Credential (Workload Identity Federation) について解説します。

Service Principal (サービスプリンシパル) とは​

Azureにおける「ユーザー」のIDがUser Principalであるのに対し、アプリケーションやサービスがAzureリソースにアクセスするために使用するIDを Service Principal と呼びます。

アプリケーション登録とサービスプリンシパルの関係​

Microsoft Entra ID (旧 Azure AD) では、アプリケーションの定義と実際のIDは以下のように分離されています。

  1. Application Object (アプリの登録):

    • アプリケーションの定義（設計図）。
    • テナント内で一意の「Application ID (Client ID)」を持ちます。
    • 必要な権限やリダイレクトURIなどが定義されます。

  2. Service Principal Object:

    • 特定のテナント内で実際に動作するアプリケーションのインスタンス（実体）。
    • Azure RBAC (Role-Based Access Control) で権限を割り当てる対象はこのService Principalです。

認証情報の種類​

Service Principalが認証を行うためには、以下のいずれかの認証情報 (Credentials) が必要です。

  • パスワード (Client Secret): 文字列のシークレット。有効期限管理や漏洩リスクの管理が必要。
  • 証明書 (Certificate): 公開鍵証明書を使用。シークレットより安全だが、証明書の管理が必要。
  • Federated Identity Credential: 後述する、外部IDプロバイダーとの信頼関係に基づく認証。

Managed Identity (マネージド ID)​

Service Principalの管理（特にシークレットの管理）を簡素化するために提供されているのが Managed Identity です。

  • 仕組み: Azureリソース（VM, App Service, Functionsなど）に対して自動的にService Principalを作成し、認証情報のローテーションをAzureプラットフォームが裏側で行います。
  • メリット: 開発者がシークレットを管理する必要が一切ありません。コード内に認証情報を埋め込む必要もなくなります。
  • 種類:
    • System-assigned: リソースとライフサイクルを共にするID。リソース削除時にIDも削除される。
    • User-assigned: 独立して作成できるID。複数のリソースで共有可能。

Azureリソース間でのアクセス（例: App ServiceからSQL Databaseへアクセス）の場合は、可能な限りManaged Identityを使用することが推奨されます。

Federated Identity Credential (Workload Identity Federation)​

Azure外部のシステム（GitHub Actions, Kubernetes, GitLab CIなど）からAzureへアクセスする場合、従来はService PrincipalのClient Secretを発行し、それを外部システムに保存する必要がありました。しかし、これにはシークレット漏洩のリスクが伴います。

Workload Identity Federation を使用すると、シークレット（パスワードや証明書）を管理することなく、外部のIDプロバイダー (IdP) との信頼関係に基づいてアクセストークンを取得できます。

仕組み (OIDC)​

OpenID Connect (OIDC) プロトコルを使用して、以下のようなフローで認証が行われます。

  1. 外部IdP (例: GitHub) が、現在のジョブやワークロードの身元を証明する OIDCトークン を発行します。
  2. 外部システムは、このOIDCトークンをAzure ADに送信します。
  3. Azure ADは、事前に設定された Federated Identity Credential の設定（Issuer, Subjectなど）とトークンを検証します。
  4. 検証が成功すると、Azure ADはService Principalの アクセストークン を返します。
  5. 外部システムはこのアクセストークンを使用してAzureリソースを操作します。

GitHub Actionsでの利用例​

GitHub ActionsからAzureへデプロイする場合、現在は azure/login アクションでOIDCを使用するのがベストプラクティスです。

1. Azure側での設定​

Service Principalに対して、Federated Identity Credentialを追加します。

  • Issuer: https://token.actions.githubusercontent.com
  • Subject Identifier: repo:<org>/<repo>:ref:refs/heads/<branch> (例: repo:my-org/my-repo:ref:refs/heads/main)

2. GitHub Actionsワークフロー​

permissions:
  id-token: write # OIDCトークンを要求するために必要
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Azure Login
        uses: azure/login@v1
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
          # client-secret は不要！

メリット​

  • シークレットレス: 長期間有効なシークレット（パスワード）が存在しないため、漏洩リスクがない。
  • 詳細なスコープ制御: 特定のリポジトリ、特定のブランチ、特定のEnvironmentからのみアクセスを許可するといった細かい制御が可能。
  • 管理コスト削減: シークレットのローテーション作業が不要。

まとめ​

  • Service Principal: アプリケーションのためのID。
  • Managed Identity: Azureリソースのための、シークレット管理不要なService Principal。Azure内部での通信に最適。
  • Federated Identity Credential: 外部システム（GitHub Actions等）からAzureへの、シークレットレスな認証方式。CI/CDパイプライン等に最適。

セキュリティ向上のため、可能な限りManaged IdentityやWorkload Identity Federationを使用し、Client Secretの使用は避けることが推奨されます。