Retirement of Azure DevOps issuer in Workload identity federation service connections は、Azure DevOpsのサービス接続で使われるWorkload identity federationの発行者を、従来のAzure DevOps issuerからMicrosoft Entra issuerへ移行するための廃止告知です。結論からいうと、Azure public cloudで、単一テナントのMicrosoft EntraアプリケーションまたはマネージドIDを使ったWorkload identity federationサービス接続を利用している場合は、2027年7月1日までに対象のサービス接続を確認し、Microsoft Entra issuerへ変換する必要があります。既存のパイプラインがすぐ停止するわけではありませんが、警告が出始めるため、運用担当者は早めに棚卸ししておくのが安全です。(Microsoft for Developers)
Retirement of Azure DevOps issuer in Workload identity federation service connections は何が変わった？
今回の変更は、Azure DevOpsのパイプラインからAzureリソースへ認証する際に使うWorkload identity federation service connectionsの発行者、つまりissuerを変更するものです。
これまで一部の既存サービス接続では、Azure DevOps issuerとして次のURLプレフィックスが使われていました。
https://vstoken.dev.azure.com今後は、Microsoft Entra issuerとして次のURLプレフィックスを使う方式へ標準化されます。
https://login.microsoftonline.com/Azure DevOps Blogでは、この変更を「Retirement」として案内しており、Azure DevOps issuerは2027年7月1日にサポート終了予定です。MicrosoftはWorkload identity federationを実装するAzureサービス全体で、Microsoft Entra issuerへ標準化する方針を示しています。(Microsoft for Developers)
すぐに押さえるべき結論
| 確認項目 | 内容 |
|---|---|
| 変更対象 | Azure DevOps issuerを使うWorkload identity federationサービス接続 |
| 従来のissuer | https://vstoken.dev.azure.com |
| 移行後のissuer | https://login.microsoftonline.com/ |
| 非推奨開始 | 2026年7月1日 |
| サポート終了予定 | 2027年7月1日 |
| 既存パイプラインへの即時影響 | すぐには停止しない |
| 必要な対応 | 対象サービス接続を確認し、Microsoft Entra issuerへ変換する |
重要なのは、「Azure DevOps全体が使えなくなる」という話ではない点です。影響を受けるのは、特定の条件に当てはまるWorkload identity federationサービス接続です。
そもそもWorkload identity federationサービス接続とは
Azure DevOpsのサービス接続は、Azure PipelinesからAzure、Docker Registry、Kubernetes、外部サービスなどへ接続するための認証設定です。Microsoft Learnでは、サービス接続を「Azure Pipelinesと外部またはリモートサービスの間の認証済み接続」と説明しています。(Microsoft Learn)
Workload identity federationは、長期間有効なクライアントシークレットをパイプラインに持たせずに認証できる方式です。従来の「アプリ登録＋シークレット」方式では、シークレットの期限切れ、漏えい、ローテーション漏れが運用リスクになりがちでした。Workload identity federationでは、パイプライン実行時にフェデレーションされたIDを使って認証するため、CI/CD環境の資格情報管理を安全にしやすくなります。
ただし、今回のRetirementはWorkload identity federation自体の廃止ではありません。Workload identity federationで使うissuerのうち、Azure DevOps issuerを段階的に廃止し、Microsoft Entra issuerへ寄せるという変更です。
変更スケジュール
Azure DevOps利用者が最も注意すべき日付は、2026年7月1日と2027年7月1日です。
| 時期 | 変更内容 | 実務上の意味 |
|---|---|---|
| 2025年11月以降 | 新規作成されるWorkload identity federationサービス接続はMicrosoft Entra issuerを既定で使用 | 最近作成したサービス接続は、すでに対象外の可能性が高い |
| 2026年7月1日 | Azure DevOps issuerが非推奨化 | 既存の対象サービス接続に警告が出る |
| 2026年7月〜2027年6月 | パイプライン実行時やサービス接続画面で警告表示 | 棚卸しと移行作業の猶予期間 |
| 2027年7月1日 | Azure DevOps issuerがサポート終了予定 | 未移行の対象サービス接続は認証失敗のリスクがある |
公式ブログでは、Azure DevOps issuerを使う既存サービス接続は2027年7月1日のRetirementまでは動作を継続すると説明されています。つまり、今すぐ障害になる変更ではありません。ただし、期限直前に対応すると、権限不足や所有者不明のアプリ登録が原因で移行が止まることがあります。(Microsoft for Developers)
影響を受ける対象者
影響を受ける可能性が高いのは、Azure DevOps ServicesでAzure Pipelinesを使い、Workload identity federationのサービス接続を運用しているチームです。
特に次のような環境では確認をおすすめします。
- Azure Resource Managerサービス接続をWorkload identity federationで作成している
- Azure PipelinesからAzureサブスクリプション、リソースグループ、Azure Container Registryなどへデプロイしている
- 過去にシークレットレス認証へ移行したサービス接続がある
- サービス接続を手動ではなくテンプレートやスクリプトで作成している
- Azure DevOps管理者とAzure／Microsoft Entra管理者が別チームになっている
Microsoft Learnでは、変換対象はAzure Resource Managerサービス接続に限られず、Azure DevOps issuerを使うWorkload identity federationサービス接続であれば、Dockerサービス接続や拡張機能で作成されたサービス接続も含まれる可能性があると説明されています。(Microsoft Learn)
影響を受けるサービス接続と対象外のサービス接続
今回の告知では、対象と対象外が明確に分かれています。ここを誤解すると、不要な作業を増やしてしまいます。
| 区分 | 対象か | 確認ポイント |
|---|---|---|
| Azure public cloudで単一テナントMicrosoft Entraアプリを使うWIFサービス接続 | 対象 | Azure DevOps issuerなら変換が必要 |
| Azure public cloudでマネージドIDを使うWIFサービス接続 | 対象 | Azure DevOps issuerなら変換が必要 |
| すでにMicrosoft Entra issuerを使っているサービス接続 | 対象外 | 追加対応は基本不要 |
| Azure Government向けサービス接続 | 対象外 | 今回のRetirement対象外 |
| Azure China向けサービス接続 | 対象外 | 今回のRetirement対象外 |
| Azure Stack向けサービス接続 | 対象外 | 今回のRetirement対象外 |
| マルチテナントアプリを使うサービス接続 | 対象外 | Azure DevOps issuerのサポートは継続 |
| クライアントシークレット方式の古いサービス接続 | 直接の対象ではない | ただし別途WIF化を検討する価値あり |
公式ブログでは、今回の非推奨化はAzure public cloudで単一テナントMicrosoft EntraアプリケーションまたはマネージドIDを使うサービス接続に適用される一方、非パブリッククラウドやマルチテナントアプリは対象外とされています。(Microsoft for Developers)
Azure DevOps利用者が最初に確認すべき場所
まず確認すべきなのは、Azure DevOpsの各プロジェクトにあるサービス接続一覧です。
画面から確認する手順
| 手順 | 操作 |
|---|---|
| 1 | Azure DevOpsで対象プロジェクトを開く |
| 2 | Project settingsを開く |
| 3 | Service connectionsを選択する |
| 4 | 一覧の上部に警告付きで表示されるサービス接続がないか確認する |
| 5 | 対象のサービス接続を開き、Updateボタンが表示されるか確認する |
| 6 | 変換後、関連するパイプラインを実行して認証エラーが出ないか確認する |
公式情報では、Azure DevOps issuerを使うサービス接続はサービス接続一覧の上部に表示され、対応が必要であることを示す警告が出ると説明されています。変換する場合は、対象サービス接続の画面でUpdateを選択します。(Microsoft for Developers)
パイプライン実行ログも確認する
2026年7月以降は、対象のサービス接続を参照するパイプライン実行時にも警告が表示される予定です。運用上は、サービス接続一覧だけでなく、以下も確認してください。
- 定期実行しているリリースパイプライン
- 手動実行のみで普段は動かしていないパイプライン
- 本番環境だけで使う承認付きステージ
- 古いプロジェクトに残っているデプロイ用パイプライン
- 拡張機能やテンプレートから参照しているサービス接続
特に注意したいのは、普段あまり動かさない本番用パイプラインです。毎日動くCIパイプラインは警告に気づきやすい一方、本番リリース時だけ使う接続は、期限直前まで見落とされることがあります。
変換作業で何が起きるのか
変換作業では、既存のサービス接続を削除して作り直すのではなく、Azure DevOps issuerからMicrosoft Entra issuerを使う構成へ更新します。
Microsoft Learnでは、既存のパイプライン参照を不要に変更しないために、サービス接続を作り直すのではなく、既存のサービス接続を変換することが推奨されています。(Microsoft Learn)
自動変換の基本手順
通常は、Azure DevOpsの画面から次の流れで変換します。
| 手順 | 内容 |
|---|---|
| 1 | Project settings > Service connectionsを開く |
| 2 | Azure DevOps issuerの警告が出ているサービス接続を選ぶ |
| 3 | Updateを選択する |
| 4 | もう一度Updateを選択して確認する |
| 5 | 変換完了のメッセージを確認する |
| 6 | パイプラインを再実行して動作確認する |
変換中も、既存のAzure DevOps issuerのフェデレーション資格情報は引き続き使われます。公式FAQでは、新しいMicrosoft Entra issuerのフェデレーション資格情報が機能することを確認した後、パイプラインジョブがMicrosoft Entra issuerを使い始めると説明されています。(Microsoft for Developers)
そのため、設計上は大きな停止を伴う作業ではありません。ただし、認証設定や権限が複雑な環境では、事前に検証用のパイプラインで確認してから本番系を進めるのが安全です。
自動変換できない場合の原因と対応
実務で詰まりやすいのは、Azure DevOps側の権限はあるが、Microsoft EntraやAzure側のIDを変更する権限がないケースです。
たとえば、Azure DevOpsのプロジェクト管理者はサービス接続を編集できても、アプリ登録やマネージドIDにフェデレーション資格情報を追加する権限を持っていない場合があります。
| よくある原因 | 起きること | 対応 |
|---|---|---|
| アプリ登録の所有者ではない | フェデレーション資格情報を追加できない | Microsoft Entra管理者またはアプリ所有者へ依頼する |
| マネージドIDの更新権限がない | 自動変換に失敗する | Azure側の権限を持つ担当者に作業を依頼する |
| サービス接続の管理者権限がない | Update操作ができない | Service connection administratorまたはEndpoint administrator権限を確認する |
| 発行者・サブジェクト・Audienceが一致しない | 認証エラーになる | Azure DevOpsに表示された値とEntra側の値を照合する |
| IDの所有者が不明 | 作業依頼先が分からない | アプリ登録のOwners、マネージドIDのロール割り当てを確認する |
Microsoft Learnでは、手動変換が必要な場合、Azure DevOpsが表示するIssuer、Subject identifier、Audienceなどの値をコピーし、アプリ登録またはマネージドIDのFederated credentialsに追加してから、Azure DevOps側で検証する流れが案内されています。(Microsoft Learn)
変更によるパイプライン定義への影響
多くのケースでは、YAMLパイプラインやタスク定義の修正は不要です。
理由は、Azure Pipelinesのタスクが参照しているのは通常、サービス接続名またはサービス接続IDであり、issuerの違いはサービス接続の内部設定として扱われるためです。公式FAQでも、Microsoft Entra issuerへの変更は通常利用時には隠れた実装詳細であり、パイプラインタスクは同じように動作し、変更は不要と説明されています。(Microsoft for Developers)
ただし、次のような環境では追加確認が必要です。
- サービス接続をREST APIやスクリプトで自動作成している
- Federated credentialのsubjectを事前に計算している
- Azure DevOps組織名、プロジェクト名、サービス接続名の変更履歴がある
- サービス接続を複数テナントや複数サブスクリプションにまたがって使っている
- 独自拡張やMarketplace拡張がサービス接続を作成している
自動化している場合は、作成時点でどのissuerを前提にしているかを確認してください。古いテンプレートやスクリプトがhttps://vstoken.dev.azure.comを固定値として持っている場合、将来的な認証失敗につながる可能性があります。
運用担当者向けの確認チェックリスト
期限まで余裕がある段階で、次の順に確認すると効率的です。
まず全体を棚卸しする
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| Workload identity federationを使うサービス接続の有無 | Project settings > Service connections | 認証方式を確認 |
| Azure DevOps issuerの警告有無 | サービス接続一覧 | 警告があれば変換対象 |
| 影響するパイプライン | Usage history、YAML、リリース定義 | 本番・検証・定期実行を分けて確認 |
| IDの種類 | サービス接続詳細、Azure側リソース | アプリ登録かマネージドIDか |
| IDの所有者 | Microsoft Entra、Azure RBAC | 変換権限を持つ担当者を特定 |
| 対象外条件 | クラウド種別、マルチテナントアプリ | 対象外なら作業不要 |
変換前に決めておくこと
変換そのものはシンプルでも、組織内の運用ルールを先に決めておくと失敗しにくくなります。
| 決めること | 理由 |
|---|---|
| 誰がAzure DevOps側でUpdateするか | サービス接続管理権限が必要 |
| 誰がMicrosoft Entra側のフェデレーション資格情報を追加できるか | 自動変換失敗時に必要 |
| どのパイプラインで動作確認するか | 本番デプロイ前に検証するため |
| 失敗時に元の接続で運用継続できるか | 変更タイミングのリスクを下げるため |
| 変更記録をどこに残すか | 後から警告や認証エラーを追跡しやすくするため |
特に大規模な組織では、Azure DevOps管理者、Azureサブスクリプション管理者、Microsoft Entra管理者が別々であることが多くあります。期限直前に「誰もアプリ登録を変更できない」と分かると、移行作業が止まります。
ありがちな失敗と回避策
サービス接続を作り直してしまう
対象のサービス接続を削除して新規作成すると、既存のパイプラインで参照しているサービス接続名や権限設定、承認とチェック、利用履歴の確認が複雑になります。
基本方針は、既存のサービス接続をUpdateで変換することです。新規作成は、既存接続が壊れている、所有者が不明、設計を見直したいなど、明確な理由がある場合に限定しましょう。
本番パイプラインだけ確認して検証系を見落とす
本番デプロイ用のサービス接続だけを確認し、検証環境や開発環境の接続を見落とすケースがあります。2027年7月以降に古い検証環境のパイプラインが失敗すると、障害調査や緊急修正の妨げになります。
プロジェクト単位ではなく、組織全体のサービス接続一覧を棚卸しする意識が必要です。
Azure DevOpsの権限だけで完結すると考えてしまう
サービス接続の変換では、Azure DevOps側だけでなく、Microsoft Entraのアプリ登録やAzureのマネージドIDに対する権限が関係します。Microsoft Learnでも、Azure DevOpsのサービス接続管理権限、マネージドIDやアプリ登録を更新する権限、対象Azureリソースへのロール割り当て権限を事前に確認するよう説明されています。(Microsoft Learn)
作業前に、次の担当者を明確にしておくと安全です。
- Azure DevOpsのプロジェクト管理者
- サービス接続管理者
- Microsoft Entraのアプリ登録所有者
- マネージドIDを管理できるAzure管理者
- 対象サブスクリプションまたはリソースグループの権限管理者
警告が出ていないから対象外と判断する
警告表示は便利ですが、すべての環境で即座に全体像を把握できるとは限りません。プロジェクトが多い組織では、画面で一つずつ見るだけでは漏れが出ます。
特に自動作成されたサービス接続や古いプロジェクトは、利用者が少なく、警告に気づきにくい傾向があります。必要に応じてAzure DevOps REST APIや管理用スクリプトで棚卸しする運用も検討してください。
セキュリティ面では悪い変更ではない
今回のRetirementは、単に古い仕組みを廃止するだけではなく、Workload identity federationの実装をMicrosoft Entra issuerへ標準化する動きです。
公式ブログでは、Microsoft Entra issuerを使うことで、Microsoft Entraが発行するトークンと不変のフェデレーションsubjectを利用でき、作成されたサービス接続に対してフェデレーション資格情報が確実に使われるという利点が説明されています。(Microsoft for Developers)
実務上は、次のようなメリットが期待できます。
- Azureサービス間でWorkload identity federationの考え方をそろえやすい
- 長期シークレットを持たない構成を継続できる
- サービス接続とフェデレーション資格情報の対応関係を明確にしやすい
- 将来的な認証方式の標準化に追従しやすい
ただし、セキュリティが向上するからといって、作業を無計画に進めてよいわけではありません。認証方式の変更は、デプロイ停止に直結する可能性があります。変換後は必ずパイプラインを実行し、Azureへのログイン、リソース操作、Docker push、ARM/Bicep/Terraformなどの処理が問題なく通るか確認してください。
管理者が今すぐやるべきこと
今回の変更で最初にやるべきことは、サービス接続の棚卸しです。いきなり変換作業に入るより、対象数、所有者、影響するパイプラインを整理したほうが安全です。
おすすめの進め方は次の通りです。
| 優先度 | 対応 | 目的 |
|---|---|---|
| 高 | Project settings > Service connectionsで警告付き接続を確認 | 対象サービス接続を特定する |
| 高 | 本番デプロイに使うサービス接続を優先確認 | 業務影響の大きい接続を先に守る |
| 高 | アプリ登録・マネージドIDの所有者を確認 | 自動変換失敗時に詰まらないようにする |
| 中 | 検証環境でUpdateを実行 | 変換手順と影響を確認する |
| 中 | パイプライン実行ログの警告を監視 | 見落としを減らす |
| 中 | サービス接続作成スクリプトを確認 | 古いissuer前提の自動化を修正する |
| 低 | 作業記録と移行状況一覧を作る | 2027年7月に向けた管理をしやすくする |
小規模な環境であれば、画面からの確認とUpdateで対応できる可能性が高いです。一方、プロジェクト数やサービス接続数が多い組織では、移行対象一覧をスプレッドシートなどで管理し、対象外・対応済み・未対応・権限確認中に分けると進捗が追いやすくなります。
まとめ：2027年7月までにAzure DevOps issuerのサービス接続を変換する
Retirement of Azure DevOps issuer in Workload identity federation service connections は、Azure DevOpsのWorkload identity federationサービス接続で使われるissuerを、Azure DevOps issuerからMicrosoft Entra issuerへ移行するための廃止告知です。
既存パイプラインがすぐ壊れる変更ではありません。しかし、2027年7月1日にAzure DevOps issuerがサポート終了予定であるため、対象のサービス接続を放置すると将来的に認証失敗につながる可能性があります。
まずは、Azure DevOpsのProject settings > Service connectionsを開き、警告が出ているサービス接続を確認してください。次に、影響するパイプライン、アプリ登録またはマネージドIDの所有者、変換に必要な権限を整理します。検証環境からUpdateを実行し、問題がなければ本番系のサービス接続も計画的にMicrosoft Entra issuerへ変換しましょう。
コメント