Azure DevOps から Azure Pipelines で ACR へコンテナイメージを Push する際のサービスコネクションの注意点とその対策
2024-08-09
はじめに
Azure DevOps は、ソフトウェア開発のライフサイクル全体をサポートする強力なプラットフォームです。しかし、初めて使用する方や、特定の機能に不慣れな方にとっては、その豊富な機能が時として複雑に感じられることがあります。今回は、Azure DevOps の重要な機能の一つである Azure Pipelines を使用して、Azure Container Registry (ACR) にコンテナイメージをプッシュする際の注意点とベストプラクティスについて詳しく解説します。
Azure DevOps とは
Azure DevOps は、Microsoft が提供する開発者向けのサービスセットです。計画立案、コード管理、ビルド自動化、テスト、デプロイメントなど、アプリケーション開発のあらゆる段階をサポートします。その中でも Azure Pipelines は、継続的インテグレーション/継続的デリバリー (CI/CD) を実現するための強力なツールです。
Azure Pipelines を使用したACRへのイメージプッシュ
Azure Pipelines を使って ACR にコンテナイメージをプッシュする際、多くの場合サービスコネクションを利用します。サービスコネクションは、外部サービス(この場合は ACR)との安全な接続を確立するための仕組みです。
サービスコネクション作成時の注意点
サービスコネクションを Docker Registry コネクションとして作成し、ACR 用に設定する際、Authentication Type の選択が必要になります。ここで注意が必要なのは、ServicePrincipal を選択した場合の動作です。

サービスコネクション作成の詳細と注意点
- Microsoft Entra ID アプリの自動登録
- Authentication Type を ServicePrincipal にすると、Microsoft Entra ID (旧 Azure Active Directory) にアプリが自動で登録されます。
- シークレットキーの自動生成
- 登録されたアプリには、認証用のシークレットキーが自動的に作成されます。
- 重要: 自動生成されるシークレットの有効期限は 3ヶ月間 に設定されます。
- 潜在的な問題
- 自動作成されるシークレットキーの有効期限が3ヶ月であるということは、つまりサービスコネクション作成から3ヶ月後、シークレットの有効期限が切れ認証エラーが発生します。
- これにより、パイプラインの実行が突然失敗する可能性があります。
- 対策案
- 有効期限が無期限のシークレットを作成する
- Authentication Type を Workload Identity federation として設定する
この自動生成されるシークレットの有効期限の短さが、多くの開発者を悩ませる原因となっています。3ヶ月後に突然パイプラインが失敗し始めるため、その原因特定に時間がかかることもあります。
各対策の詳細について、以下で解説します。
対策1: 有効期限が無期限のシークレットを作成する
この問題に対する一つの解決策は、有効期限が無期限のシークレットを作成することです。一方で、これには注意点があります。
無期限のシークレット作成手順とその注意点について見ていきましょう。
無期限シークレットの作成手順
- Azure ポータルからの作成は不可能
- セキュリティ上の理由から、Azure ポータルの UI からは有効期限が無期限のシークレットを作成できません。
- 詳細は Azure サポートのこちらの記事を参照してください。
- Azure CLI を使用
- 一方で、Azure CLI を使用すると、簡単に無期限シークレットを作成できます。(上記の記事では PowerShell での作成方法に言及がありますが、ここではより簡単(と思われる) Azure CLI による作成方法を紹介します。
- 使用するコマンド:
az ad app credential reset --id <Application ID or Object ID> --append --end-date "2299-12-31"
このコマンドにより、2299年12月31日まで有効な(事実上無期限の)シークレットが作成されます。
コマンドの詳細は公式ドキュメントを参照してください。
- 注意点
無期限シークレットの使用はセキュリティリスクを増大させる可能性があります。
定期的なローテーションや監視が重要です。
対策2: Workload Identity federation を使用する
もう一つの、そしてより推奨される対策は、Workload Identity federation を使用することです。これは比較的新しい認証方式で、多くの利点があります。
Workload Identity federation とは、Azure サービスで実行されるアプリケーションやワークロードが、Microsoft Entra ID のアイデンティティを使用して他の Azure リソースに安全にアクセスできるようにする機能です。この方式では、従来のサービスプリンシパルや管理 ID に依存せずに、 Entra ID ( 旧 Azure AD) のアイデンティティを使用して Azure リソースへのアクセス権を委任・管理できます。
Workload Identity federation の主な利点:
- セキュリティの強化: 静的な認証情報を使用しないため、セキュリティリスクが低減されます。
- 管理の簡素化: シークレットや証明書の期限管理が不要になります。
- 運用の効率化: 認証情報の更新や管理にかかる手間が大幅に削減されます。
Workload Identity federation を使用するには、サービスコネクションの作成時に Authentication Type を “Workload Identity federation” として選択するだけです。

これにより、Microsoft Entra ID のアプリのフェデレーション資格情報として Azure DevOps の情報が追加されます。
Microsoft Entra ID アプリケーション

Microsoft も Workload Identity federation の使用を推奨しているため、新規にサービスコネクションを作成する場合は、この方式を選択することをお勧めします。
まとめ
Azure DevOps から Azure Pipelines を使用して ACR にコンテナイメージをプッシュする際、サービスコネクションの設定は重要なポイントです。
特に注意すべき点は以下の通りです:
- ServicePrincipal 認証を使用する場合、自動生成されるシークレットの有効期限は3ヶ月であり、期限切れによる認証エラーに注意が必要です。
- 対策として、無期限シークレットの作成や Workload Identity federation の使用が考えられます。
- 無期限シークレットは Azure CLI を使用して作成可能ですが、セキュリティリスクに注意が必要です。
- Workload Identity federation は、セキュリティと管理の観点から最も推奨される方法です。
Azure DevOps や Azure Pipelines を効果的に活用するためには、これらの注意点を理解し、適切な認証方式を選択することが重要です。特に Workload Identity federation は、セキュリティと利便性のバランスが取れた優れた選択肢となります。
Azure の世界は常に進化しており、新しい機能や best practices が登場し続けています。そのため、定期的に公式ドキュメントを確認し、最新の情報をキャッチアップすることをお勧めします。Azure DevOps と Azure Pipelines を使いこなすことで、より効率的で安全なアプリケーション開発・運用が可能になります。
弊社のご紹介
弊社ではAzure構築・アドバイザリーサービスを提供しております。
マイクロソフト出身、 Azure 認定資格を保持するエンジニアが Azure に関するアドバイスや、環境構築などのご支援をいたします。
また、マイクロソフトのAzureサポートとのやり取りも弊社にお任せいただけます。
サポート担当とのやり取りは、慣れていない場合適切な情報を引き出すことができず、連絡の往復が続き問題解決までに時間がかかることが多いです。
弊社のアドバイザリーサービスでは、弊社で回答できる部分は迅速に回答し、Azure内部の調査が必要な場合などはAzureサポートと連携して問題解決にあたることができます。
Azure をより活用し、最適な構成を構築するご支援をいたしますので、ご検討の方はお気軽にお問い合わせください。
Azureに強い福岡のシステム開発会社 | 株式会社ウィズワンダー