Service connections – Azure Pipelinesを使ってAzureへデプロイしている場合、まず確認すべきことは「接続をすぐ作り直すべきか」ではなく、どのサービス接続が、どの認証方式で、どのパイプラインから使える状態になっているかです。2026年5月時点の公式情報では、Service Connections管理画面の視認性向上、個別パイプライン承認の推奨、Workload Identity Federationへの移行、接続タイプごとの注意点が重要な確認ポイントになります。(Microsoft Learn)
Service connectionsは、Azure PipelinesからAzure、GitHub、Docker Registry、Kubernetes、Mavenなどの外部サービスへ接続するための認証済み接続です。つまり、設定ミスがあると「デプロイが失敗する」だけでなく、「本来使うべきでないパイプラインから本番環境へアクセスできる」といったセキュリティリスクにもつながります。(Microsoft Learn)
Service connections – Azure Pipelinesとは
Service connections – Azure Pipelinesは、Azure Pipelinesのジョブ内で外部サービスやリモートサービスを利用するための接続設定です。たとえば、Azure App ServiceへデプロイするためのAzure Resource Manager接続、コンテナイメージを扱うDocker Registry接続、別のAzure DevOps組織のリポジトリを参照するAzure DevOps接続などが該当します。(Microsoft Learn)
実務では、次のような場面で使われます。
| 利用シーン | 代表的なサービス接続 | 確認すべきポイント |
|---|---|---|
| Azureリソースへデプロイする | Azure Resource Manager | Workload Identity Federationを使えるか、スコープが広すぎないか |
| ACRへイメージをpush/pullする | Docker Registry / Azure Container Registry | 認証方式、レジストリ単位の権限、パイプライン承認 |
| 別組織のAzure Reposを参照する | Azure DevOps | PATではなくEntra Workload Identityを使えるか |
| AKSへデプロイする | Kubernetes / Azure Resource Manager | private clusterの場合にエージェントが到達できるか |
| GitHubや外部Gitを使う | GitHub / Other Git | PATやOAuthの管理、リポジトリ権限 |
ポイントは、Service connectionを「便利な接続先リスト」として見るのではなく、CI/CDから外部リソースへ到達するための権限境界として管理することです。
今回押さえるべき変更点
公式リリースノートでは、Service Connections管理ページが改善され、接続タイプや認証方式などの詳細情報を確認できるようになり、それらの項目でフィルターできるようになったと説明されています。ただし、追加の詳細情報は新しく作成されたサービス接続で利用できるとされているため、既存の接続で情報が見えない場合でも、ただちに異常とは判断しないほうがよいでしょう。(Microsoft Learn)
この変更の実務上の意味は、棚卸しがしやすくなることです。以前は、サービス接続名だけでは「本番用なのか」「シークレット認証なのか」「Workload Identity Federationなのか」が分かりにくいケースがありました。今後は、管理画面上で認証方式や接続タイプを確認し、危険度の高い接続を優先して見直しやすくなります。
変更点の整理
| 確認項目 | 何が変わる・何を確認するか | 実務上の影響 |
|---|---|---|
| 管理画面の表示 | 接続タイプや認証方式の可視性が向上 | シークレット認証の接続や本番系接続を探しやすくなる |
| フィルター | 接続タイプ・認証方式で絞り込み可能 | 棚卸し、監査、移行計画が立てやすくなる |
| 新規接続の詳細 | 追加詳細は新しく作成された接続が対象 | 古い接続は別途手動確認が必要 |
| パイプライン承認 | すべてのパイプラインへ一括許可は非推奨 | 本番接続は個別承認を基本にする |
| 認証方式 | Azure Resource ManagerではWorkload Identity Federationが推奨 | シークレットの期限切れ・ローテーション負荷を減らせる |
影響を受ける対象者
今回の確認ポイントは、Azure Pipelinesを触る開発者だけでなく、Azure DevOps組織の管理者、セキュリティ担当、インフラ担当にも関係します。
| 対象者 | 主な影響 | まず確認すること |
|---|---|---|
| Azure DevOps管理者 | サービス接続の作成権限、利用権限、共有範囲の見直し | Endpoint Administrators / Endpoint Creatorsのメンバー |
| プロジェクト管理者 | 各プロジェクト内のService connections管理 | 本番用接続がOpen accessになっていないか |
| 開発者 | YAMLやClassic Pipelineで参照する接続名の管理 | タスク内の接続名が正しいか |
| セキュリティ担当 | シークレット認証、PAT、過剰権限の検出 | 認証方式、Usage history、監査ログ |
| インフラ担当 | Azure、AKS、ACR、Key Vaultなどへの接続 | スコープ、RBAC、ネットワーク到達性 |
特に本番環境へデプロイするサービス接続は、単なる開発設定ではなく、Azureリソースへの実行権限を持つ重要な資産です。開発チームだけで完結させず、Azure側のRBACやMicrosoft Entra IDの管理者とも一緒に確認するのが安全です。
管理者が最初に確認すべき設定
Service connectionsの管理は、Azure DevOpsプロジェクトの Project settings > Service connections から行います。公式ドキュメントでは、作成、表示、編集、利用、パイプライン承認の流れが整理されています。(Microsoft Learn)
接続一覧で認証方式と接続タイプを棚卸しする
まず、すべてのサービス接続を一覧化します。新しい管理画面で接続タイプや認証方式が見える場合は、それを使って次のように分類します。
| 分類 | 例 | 優先度 |
|---|---|---|
| 本番Azureへ接続する | Azure Resource Manager、ACR、AKS | 最優先 |
| シークレットやPATを使う | Service principal secret、GitHub PAT、Basic認証 | 高 |
| 全パイプラインに開放されている | Open access、Grant access permission to all pipelines | 高 |
| 複数プロジェクトで共有されている | Cross-project service connection | 高 |
| 長期間使われていない | Usage historyに最近の利用がない | 中 |
| 非推奨に近い代替候補がある | Azure Service Bus service connectionなど | 中 |
ここで重要なのは、接続名だけで判断しないことです。prod-azure のような名前でも、実際には検証環境用のサブスクリプションを指していることがあります。逆に、test-connection という名前のまま本番デプロイに使われているケースもあります。
「すべてのパイプラインにアクセス許可」を見直す
Service connection作成時には、すべてのパイプラインにアクセスを許可するオプションがあります。しかし公式ドキュメントでは、このオプションは推奨されておらず、各パイプラインを個別に承認することが推奨されています。(Microsoft Learn)
本番環境、共有サブスクリプション、顧客データに触れる環境では、原則として「全パイプライン許可」は避けます。必要なパイプラインだけを承認し、利用理由を説明欄や運用台帳に残すと、後から監査しやすくなります。
ユーザー・グループのロールを確認する
Service connectionには、Reader、User、Creator、Administratorといったロールがあります。UserはClassicとYAMLのビルド・リリースパイプラインでサービス接続を利用でき、Administratorは利用に加えて他ユーザーやグループのロール管理もできます。(Microsoft Learn)
| ロール | できること | 付与の目安 |
|---|---|---|
| Reader | サービス接続を閲覧 | 監査担当、運用確認担当 |
| User | パイプラインで利用 | 対象パイプラインを管理するチーム |
| Creator | プロジェクト内で作成 | DevOps管理者、限られたリード担当 |
| Administrator | 利用と権限管理 | プロジェクト管理者、サービス接続管理者 |
よくある失敗は、開発チーム全員にAdministrator相当の権限を与えてしまうことです。これでは、意図しない接続先変更やパイプライン開放が起きても検知しにくくなります。通常は、作成・管理できる人と、利用だけできる人を分けるべきです。
パイプライン権限をRestricted accessにする
個別のService connectionでは、すべてのパイプラインが使えるOpen accessと、指定したパイプラインだけが使える制限付きアクセスを設定できます。公式ドキュメントでは、Open accessからRestrict accessへ切り替えたり、特定のパイプラインを追加したりできることが説明されています。(Microsoft Learn)
本番用Service connectionでは、次の基準で考えると判断しやすくなります。
| 接続の種類 | 推奨設定 |
|---|---|
| 本番Azureサブスクリプション | Restricted access |
| 本番ACR | Restricted access |
| 検証環境の一時接続 | 用途次第でRestricted access |
| 全社共通の読み取り専用接続 | 権限を絞ったうえでOpen accessを検討 |
| 秘密情報や顧客データに関係する接続 | Restricted access必須 |
開発者が確認すべきYAMLとタスク設定
開発者側で最も多いトラブルは、Service connection名の不一致です。YAMLパイプラインでは、タスクの入力値としてサービス接続名を指定します。公式ドキュメントでも、YAMLでは接続名を azureSubscription などの値として使うと説明されています。(Microsoft Learn)
例として、Azureへデプロイするタスクでは次のように指定します。
steps:
- task: AzureCLI@2
inputs:
azureSubscription: 'prod-arm-wif'
scriptType: 'bash'
scriptLocation: 'inlineScript'
inlineScript: |
az group list --output tableこのとき、prod-arm-wif はAzure DevOpsのService connectionsに存在する接続名と一致している必要があります。接続名を変更すると、YAML側も修正しない限りパイプラインが失敗します。
サービス接続名の命名ルールを決める
Service connectionは後から増えやすいため、名前にルールを持たせると管理しやすくなります。
| 命名要素 | 例 | 理由 |
|---|---|---|
| 環境 | prod、stg、dev | 本番・検証を見分ける |
| 接続先 | arm、acr、azdo、aks | 接続タイプを見分ける |
| 認証方式 | wif、mi、sp | 移行対象を見つけやすくする |
| スコープ | rg-app01、sub-main | 影響範囲を想像しやすくする |
たとえば、prod-arm-wif-rg-app01 のようにしておくと、「本番」「Azure Resource Manager」「Workload Identity Federation」「特定リソースグループ向け」と分かります。長すぎる名前は扱いづらいため、チーム内で略語を統一することも大切です。
Workload Identity Federationへの移行判断
Azure Resource Manager service connectionでは、公式ドキュメントがWorkload Identity Federationの利用を推奨しています。シークレットや証明書を管理せずに認証できるため、期限切れやローテーション漏れによるデプロイ停止を減らせます。(Microsoft Learn)
新規作成ならWorkload Identity Federationを優先する
新しくAzure Resource Manager接続を作る場合は、まずWorkload Identity Federationを使えるか確認します。公式ドキュメントでは、サブスクリプションのOwnerロールがあること、Azure StackやAzure US Government環境ではないこと、利用するMarketplace拡張機能タスクがWorkload Identity Federationをサポートしていることなどが、自動作成を使う条件として挙げられています。(Microsoft Learn)
| 状況 | 選びたい方式 |
|---|---|
| 新規にAzureへ接続する | App registration with Workload Identity Federation |
| アプリ登録を作る権限がない | 既存のユーザー割り当てマネージドID |
| 既存のサービスプリンシパルを使う必要がある | 手動構成 |
| Azure Stackや特殊な環境 | 公式要件を確認して個別判断 |
| 古い拡張機能タスクを使う | WIF対応状況を確認してから移行 |
既存接続は変換できる条件を確認する
既存のAzure Resource Manager service connectionは、条件を満たせばWorkload Identity Federationへ変換できます。ただし、変換ツールを使えるのは、Azure DevOpsが元々作成した接続で、かつ1つのプロジェクトだけで使われている接続です。手動作成した接続やクロスプロジェクトの接続は、変換ツールでは変換できないとされています。(Microsoft Learn)
また、変換後に元へ戻す場合は7日以内に戻す必要があると説明されています。移行時は、いきなり本番接続を変換するのではなく、検証環境で変換、パイプライン実行、ロール確認、ロールバック手順確認まで済ませてから本番に適用するのが安全です。(Microsoft Learn)
Azure DevOps接続はPATレス化を検討する
Azure DevOps service connectionは、Azure DevOpsリソースへPersonal Access Tokenなしで認証するための接続タイプです。公式ドキュメントでは、Microsoft Entra Workload Identityを使うことで、PATの作成、保存、ローテーションを不要にできると説明されています。(Microsoft Learn)
利用シーンとしては、別組織のAzure Reposをcheckoutする、Azure Artifactsフィードへアクセスする、Azure DevOps REST APIをインラインスクリプトから呼び出す、Visual Studio Marketplaceへ拡張機能を公開する、といったケースが挙げられています。(Microsoft Learn)
Azure DevOps接続で失敗しやすいポイント
| 失敗例 | 原因 | 対処 |
|---|---|---|
| 接続作成に失敗する | サービスプリンシパルやマネージドIDが組織に追加されていない | Organization Settings > Usersで追加する |
| クロス組織アクセスできない | 対象組織側にもIDが追加されていない | 両方の組織でユーザー追加と権限付与を確認する |
| YAMLでcheckoutできない | endpoint名やリポジトリ名が違う | Service connection名とrepository resource設定を確認する |
| 権限が強すぎる | 共通IDに広い権限を与えている | パイプライン・プロジェクト・組織単位で接続を分ける |
PATは手軽ですが、期限管理や漏えい時の影響範囲が問題になりやすい認証方式です。別組織のリポジトリやArtifactsを継続的に使う場合は、Azure DevOps service connectionによるPATレス化を検討する価値があります。
接続タイプ別の移行・展開上の注意点
Service connectionsは種類によって注意点が異なります。単に「WIFにすれば安全」と考えるのではなく、接続先、タスク、ネットワーク、RBACを合わせて確認する必要があります。
| 接続タイプ | 注意点 | 推奨アクション |
|---|---|---|
| Azure Resource Manager | WIFが推奨。古いシークレット方式は後方互換やエッジケース向け | 新規はWIF、既存は変換可否を確認 |
| Azure Container Registry | Service Principal、Managed Identity、Workload Identity Federationを選択可能 | ACRごとに必要最小権限を付与 |
| Azure DevOps | Entra Workload IdentityでPATレス認証が可能 | クロス組織利用時は対象組織にもIDを追加 |
| Azure Service Bus | より安全な方法としてPublish To Azure Service Bus v2タスクが案内されている | 既存のService Bus接続を棚卸し |
| Kubernetes | privateまたはネットワークから隠れたクラスターではKubernetes service connectionが機能しない | ARMベース接続と到達可能なエージェントを使う |
| Kubernetes Kubeconfig | AKS発行のユーザー証明書は2年有効と説明されている | 期限管理または別方式を検討 |
| GitHub / Other Git | PATやOAuthの権限が広くなりやすい | リポジトリ単位・用途単位で接続を分ける |
特にAKSでは、private clusterかどうかが重要です。公式ドキュメントでは、プライベートまたはネットワークから隠れたクラスターではKubernetes service connectionオプションが機能せず、Azure Resource Managerベースのサービス接続と、クラスターへ直接到達できるエージェントが必要とされています。(Microsoft Learn)
Approvals and checksで本番接続を守る
本番用Service connectionには、Approvals and checksを設定すると、パイプラインがリソースを使う前に承認や検査を挟めます。公式ドキュメントでは、チェックはYAMLではなくリソース管理者がWeb UIで管理し、環境、サービス接続、エージェントプール、変数グループ、セキュアファイルなどに設定できると説明されています。(Microsoft Learn)
本番接続で検討しやすいチェックは次のとおりです。
| チェック | 向いている場面 |
|---|---|
| Approval | 本番デプロイ前に責任者承認を必須にする |
| Branch control | refs/heads/main など許可ブランチからの実行に限定する |
| Required template | 監査・セキュリティ処理を含む共通YAMLテンプレートを強制する |
| Business hours | 深夜や休日の自動デプロイを抑制する |
| Invoke REST API / Azure Function | 外部の変更管理・脆弱性検査・リリース判定と連携する |
| Exclusive lock | 同じ本番リソースへの同時デプロイを防ぐ |
注意点として、公式ドキュメントではService connectionsは変数で指定できないと明記されています。承認やチェックを前提にする本番接続では、実行時に接続先を変数で差し替える設計にせず、どのステージがどのService connectionを使うかを明確にしておきましょう。(Microsoft Learn)
展開前のチェックリスト
本番環境へ影響するService connectionsを見直す場合は、次の順序で進めると安全です。
| 手順 | 作業 | 完了条件 |
|---|---|---|
| 1 | Service connections一覧を出す | 接続名、接続タイプ、認証方式、利用プロジェクトが分かる |
| 2 | 本番・検証・開発に分類する | 本番接続が明確に識別できる |
| 3 | Open accessを確認する | 本番接続が不要に全パイプラインへ開放されていない |
| 4 | Usage historyを見る | 使われているパイプラインと最終利用日が分かる |
| 5 | 認証方式を確認する | シークレット、PAT、WIF、Managed Identityを分類できる |
| 6 | WIF移行候補を決める | 変換可能なARM接続を抽出できる |
| 7 | 検証環境で変換・新規作成する | パイプラインが成功し、権限不足がない |
| 8 | Approvals and checksを設定する | 本番接続に承認・テンプレート・ブランチ制御を適用できる |
| 9 | YAMLの接続名を確認する | 変更後の接続名とタスク入力が一致する |
| 10 | ロールバック手順を用意する | 失敗時に旧接続または代替接続へ戻せる |
このチェックリストは、月次のCI/CD監査にも使えます。特に「使われていないのに残っている接続」「作成者が退職・異動している接続」「名前から用途が分からない接続」は、早めに整理したほうがよい対象です。
よくあるトラブルと対処法
| 症状 | よくある原因 | 対処 |
|---|---|---|
| パイプライン実行時に権限承認を求められる | Service connectionが個別承認制になっている | 必要なパイプラインだけPermitする |
| 急にAzureデプロイが失敗した | シークレット期限切れ、RBAC変更、接続名変更 | 認証方式、Azure側ロール、YAMLの接続名を確認 |
| WIFへ変換できない | 手動作成接続、クロスプロジェクト接続 | 新規WIF接続を作り、段階的に切り替える |
| AADSTS系エラーが出る | フェデレーション資格情報、Issuer、Subject、テナント制約の不一致 | Microsoft Entra側のフェデレーション設定を確認 |
| private AKSへ接続できない | エージェントがクラスターへ到達できない | クラスターへ到達可能なself-hosted agentやManaged DevOps poolを使う |
| 管理画面で認証方式が見えない | 追加詳細が新規接続中心に反映される | 既存接続は編集画面やAzure側で手動確認する |
| Entra ID側を変更したのに反映されない | Azure DevOps内部のトークンキャッシュ | しばらく待つかService connectionを更新する |
Azure DevOpsは、Entra ID認証を使うService connectionで発行されたアクセストークンを内部的にキャッシュする場合があります。キャッシュは内部フローに限られ、ユーザーへトークンが露出するものではありませんが、Entra ID側の変更直後に古い状態が見える場合は、1時間ほど待つか、該当のService endpointを更新する対応が案内されています。(Microsoft Learn)
管理ルールとして決めておきたいこと
Service connectionsは一度作ると、後から増え続けます。安全に運用するには、個別対応ではなくルール化が必要です。
| ルール | 推奨内容 |
|---|---|
| 命名規則 | 環境、接続先、認証方式、スコープを含める |
| 作成権限 | Creator以上を限られた管理者に限定する |
| 本番接続 | Restricted accessを基本にする |
| 認証方式 | 新規Azure接続はWIFを第一候補にする |
| 説明欄 | 用途、所有チーム、Azure側の権限範囲を書く |
| 棚卸し | 月次または四半期でUsage historyを確認する |
| 廃止 | 未使用接続は無効化・削除の判断をする |
| 変更管理 | 本番接続の認証方式変更は事前検証と承認を必須にする |
独自に入れておきたい観点は、Service connectionを「誰が作ったか」ではなく「どの業務リスクを持つか」で分類することです。作成者が開発者でも、接続先が本番サブスクリプションであれば管理対象は本番権限です。逆に、管理者が作った接続でも、用途が不明なまま残っていればリスクになります。
まず何から対応すべきか
最初にやるべきことは、Project settings > Service connections で接続一覧を確認し、接続タイプ、認証方式、Open accessの有無、Usage history、本番環境への到達可否を棚卸しすることです。次に、本番Azure Resource Manager接続とACR接続から優先して、Workload Identity Federationへの移行可否、個別パイプライン承認、Approvals and checksの設定を見直します。
すべてを一度に変更する必要はありません。まずは本番接続を「見える化」し、全パイプライン開放を避け、WIFへ移行できる接続を検証環境から切り替える。この順序で進めると、デプロイ停止のリスクを抑えながらService connections – Azure Pipelinesのセキュリティと運用性を改善できます。
コメント