Zenn
🕌

Azure DevOps Workload Identity Federationのススメ

2024/12/03に公開
Azure
CI/CD
Azure DevOps
tech

はじめに

Azure DevOps のAzure Reposで管理している、SrcよりAzureコンポーネントに対してCI/CDを行う際、Azure DevOpsとAzureを繋ぐ役割としてサービスコネクション（Azure接続）が必要となります。
そのコネクションの中で利用するサービスの認証方式であるWorkload Identity Federationについてのお話をします。

Workload Identity Federationは、2023年9月14日にパブリックプレビューとしてリリースされ、2024年2月13日に一般提供（GA）されました。Azure DevOps Workload Identity Federationを使用することで、Azure DevOpsはAzureリソースにより簡潔かつ安全に接続できるようになります。特に簡素にという部分の恩恵が大きく、従来の認証方法で必要だったシークレット管理を不要にし、セキュリティや運用の効率性を大幅に向上させるソリューションとなります。本記事では、改めてその仕組みやメリット、利用方法について解説したいと思います。

従来のAzureリソース接続とその課題

従来、Azure DevOpsからAzureリソースに接続するためには、以下の手順が一般的でした。

  1. Entra ID（旧AAD）でサービスプリンシパルを作成する。
  2. サービスプリンシパルに対してクライアントシークレット（パスワード）を発行する。
  3. 発行されたClient IDとClient SecretをAzure DevOpsに保存（サービスコネクションの作成）し、パイプラインから使用。

この方法には以下の課題が伴いました

  • シークレット管理の手間
    シークレットを生成、保存、ローテーションする運用負担が発生。特に、シークレットの有効期限（最長2年）を過ぎるとパイプラインが失敗し、再生成と更新作業が必要。
  • セキュリティリスク
    シークレットが誤って漏洩した場合、悪意ある第三者によるAzureリソースの不正アクセスのリスク

Workload Identity Federationとは

Workload Identity Federationは、OpenID Connect (OIDC)を使用して、Azure DevOpsとAzureリソース間の認証をシークレットレス化する仕組みです。この認証スキームにより、フェデレーション・サブジェクト（例: sc://<org>/<project>/<service connection name>）を使用して認証を実現します。

下記のような利点が挙げられます。

  1. 管理の簡素化
    • シークレットの生成・保存・更新が不要になるため、運用負荷を軽減。
    • シークレット有効期限の切れによるパイプラインエラーを回避可能。
  2. セキュリティの向上
    • 永続的なシークレットを必要とせず、機密情報漏洩のリスクを排除。
    • 本番環境へのアクセス権を含むシークレットがパイプラインで流出する懸念が解消。

利用方法

Azure Resource ManagerでWorkload Identity Federationを使用したサービスコネクションの構築方法は、2通りあります。

1. 新しいAzureサービス接続の作成

新規作成時、Azure DevOpsのサービス接続ウィザードでWorkload Identity Federationを選択します。以下の2つのオプションがあります。

  • Automatic：Azure DevOpsが自動で設定を行います。
  • Manual：利用者が詳細設定を手動で指定します。

2. 既存のサービス接続の変換

既存のAzureサービス接続（従来のシークレットベース認証）をWorkload Identity Federationに変換できます。この変換は、1接続ごとに実施可能で、以下の特徴があります。

  • 接続を利用するパイプラインの変更は不要。
  • 変換後、自動的に新しいスキームが適用されます。

Docker Registryへの対応

Workload Identity Federationは、最近になって、Azure Container Registry (ACR)を使用したDocker Registryへ対応しました。
具体的には、Azure PipelinesのDocker@2タスクを利用する際に接続されるDocker Registry用のサービスコネクションについてもシークレットの期限切れを意識しなくて済むようになります。

こんなやつですね。

  # Publish
  - stage: DockerBuildAndPush
    displayName: 'Build and Push Docker Image'
    jobs:
      - job: BuildAndPushImage
        displayName: 'Build and Push Docker Image Job'
        steps:
          - task: Docker@2
            displayName: 'Build and Push Docker image'
            inputs:
              command: buildAndPush
              repository: $(CONTAINER_IMAGE_NAME)
              dockerfile: '$(Build.SourcesDirectory)/devops/data_viz/src/Dockerfile'
              containerRegistry: $(CONTAINER_REGISTORY_SERVICE_CONNECTION_NAME)
              tags: $(CONTAINER_IMAGE_TAG)

ただし、こちらは、2024年11月時点、Manualを選べないため、AzDOと同じテナント内のAzureリソースに対してのみ利用できる理解です。間違ってたらすいません・・・コメントください。

まとめ

Workload Identity Federationは、Azure DevOpsユーザーにとってセキュリティと運用効率の両面で大きな利点を提供します。特に、従来の認証方法で課題となっていたシークレット管理の負担を解消し、リスクを低減します。新規作成や既存接続の変換を検討し、運用に活用してみてはいかがでしょうか？

https://learn.microsoft.com/ja-jp/azure/devops/pipelines/release/configure-workload-identity?view=azure-devops&tabs=managed-identity

GitHubで編集を提案

Discussion