MENU

Azureロードバランサーで異なるリソースグループ間のVMをバックエンド登録するためのRBAC最適解説

Azure

Azure ロード バランサーのバックエンドに VM を登録するとき、VM と LB が異なるリソース グループにあると「どこにどのロールを付ければよいのか」で悩みがちです。本記事では、Network Contributor / Virtual Machine Contributor を中心に、最小権限で安全に運用するための RBAC 設計を具体例とともに整理します。

目次

シナリオ整理：RG1 の VM を RG2 の Load Balancer に登録したい

まず、本記事の前提となる構成を整理します。

リソース グループ含まれるリソース役割
RG1VM1, VM2, VM3（各 VM に NIC が紐づく）アプリケーション サーバー群
RG2Load Balancer LB1（フロントエンド IP, バックエンド プール, 規則など）公開用のロード バランサー

やりたいことは単純で、「RG1 の VM（または NIC）を、RG2 の LB1 のバックエンド プールに登録する」ことです。しかし、リソースが異なる RG に分かれているため、ポータルや CLI から操作するときに、ユーザーまたはサービス プリンシパルが RG1 と RG2 の両方に対して適切な RBAC 権限 を持っている必要があります。

特に問題になりやすいのは次のポイントです。

  • NIC 参照でバックエンド プールに参加させたいが、ポータル上で VM 一覧が表示されない
  • バックエンド プールに追加はできるが、ロード バランシング規則や NAT 規則を編集するとエラーになる
  • LB リソース単体に Network Contributor を割り当てる設計はアリか / ナシか

以下では、これらの疑問に答えつつ、実運用を見据えた RBAC 設計のパターンを解説します。

Azure RBAC と Network Contributor / Virtual Machine Contributor の役割

本題に入る前に、関連する代表的なロールのイメージをざっくり押さえておきます。

ロール名主な対象できることのイメージできないことのイメージ
Network ContributorMicrosoft.Network 配下のリソース
（VNet, NIC, LB, NSG など）		ロード バランサーの作成・変更 バックエンド プール・LB 規則・NAT 規則・ヘルス プローブの編集 NIC, VNet, NSG などネットワーク関連の変更VM 本体（Microsoft.Compute/virtualMachines）の作成・削除・サイズ変更 ストレージ アカウントや Key Vault など、ネットワーク以外のリソース操作
Virtual Machine ContributorMicrosoft.Compute/virtualMachines などVM の作成・削除・起動/停止 VM のプロパティ参照（NIC の情報を含む）ネットワーク リソース単体（VNet, LB など）の作成・変更

ポイントは、Portal で「VM を選択して LB バックエンドに追加する」場合、裏側では ネットワーク情報だけでなく VM リソース情報の参照も行う ため、Network Contributor だけでは UI 上で VM を選択できないケースがある、という点です。

質問1：Network Contributor は RG1 と RG2 の両方に必要か？

結論から言うと、次のように整理できます。

操作内容必要なスコープ必要なロール説明
LB1 のバックエンド プールを編集し、
IP アドレス直入力で登録する		RG2（LB1 が存在）Network ContributorIP アドレス直入力の場合、実際に更新されるのは LB1 の構成だけであり、NIC や VM のプロパティを変更しないため、RG2 側の権限のみで完結します。
「NIC/VM 参照」でバックエンド プールに登録するRG1（VM/NIC）と RG2（LB1）の両方RG1：Network Contributor + Virtual Machine Contributor
RG2：Network Contributor		LB のバックエンド プール構成変更は RG2 の権限で行いますが、ポータルで VM/NIC 一覧を取得するために RG1 側の読み取り権限、場合によっては NIC を更新する権限が必要になります。

したがって、IP アドレス固定で運用し、ポータル上の「VM/NIC を選択する UI を使わない」のであれば、Network Contributor は RG2 にだけ付与しても動作します。一方、運用上よくある「バックエンドに追加する VM を GUI から選びたい」場合は、RG1 側にもロールを付与する必要があります。

実務的なおすすめ

  • LB バックエンドを NIC 参照 で構成する場合
    • RG1：Network Contributor + Virtual Machine Contributor
    • RG2：Network Contributor
  • LB バックエンドを IP アドレス固定 で構成し、VM 側の情報をポータルで触らせたくない場合
    • RG2 のみに Network Contributor（もしくは後述のカスタム ロール）
    • RG1 にはロールを付与しない、または Reader 程度にとどめる

質問2：NIC 参照や LB 規則・NAT 規則・ヘルス プローブ作成時に必要な権限

次に、「NIC 参照でバックエンド プールに登録したい」「ロード バランシング規則、NAT 規則、ヘルス プローブも作りたい」という場合に必要となる権限をもう少し細かく見ていきます。

NIC 参照でバックエンド プールに VM を登録する場合

ポータルで LB1 のバックエンド プールを編集し、以下の経路で登録するとします。

  • バックエンド プール → 「+ 追加」 → 「VM を選択」または「NIC を選択」

このとき発生する代表的な操作は次のとおりです。

処理アクセス対象必要となるロールの例
VM / NIC 一覧の取得RG1 内の Microsoft.Compute/virtualMachines
および Microsoft.Network/networkInterfaces		Virtual Machine Contributor またはそれに準ずる参照権限
バックエンド プールへの参加設定LB1（RG2）および対象 NIC（RG1）RG1: Network Contributor（NIC 更新）
RG2: Network Contributor（LB1 更新）

特にポータル UI に依存する場合、VM 一覧取得のために Microsoft.Compute/virtualMachines/read 相当の権限が必要になるため、単なる Network Contributor だけでは VM 一覧が表示されず、IP アドレスを直接指定する画面にしか進めない、といった挙動になります。

このため、「ポータルで VM を選んで登録したい」なら、RG1 に Virtual Machine Contributor を付与しておくのが現実的です。

ロード バランシング規則・NAT 規則・ヘルス プローブの作成に必要な権限

これらはすべて LB1 リソース（Microsoft.Network/loadBalancers）配下の構成要素です。そのため、以下のようなイメージですべて RG2 側の Network Contributor に含まれるアクションで操作できます。

構成要素代表的な操作主に関わるアクションの例必要なロール
バックエンド プール作成・削除・VM/NIC 追加Microsoft.Network/loadBalancers/backendAddressPools/*RG2 の Network Contributor
ロード バランシング規則作成・削除・ポート番号の変更Microsoft.Network/loadBalancers/loadBalancingRules/*RG2 の Network Contributor
インバウンド NAT 規則ポート フォワーディング設定Microsoft.Network/loadBalancers/inboundNatRules/*RG2 の Network Contributor
ヘルス プローブプロトコル・ポート・間隔の設定Microsoft.Network/loadBalancers/probes/*RG2 の Network Contributor

つまり、規則やプローブを含めて LB1 を一通り管理させたい場合は、RG2 に対して Network Contributor を与えれば足りる、ということになります。

「LB の規則は触らせたくない」場合の考え方

一方で、バックエンドへの登録のみを委任し、ロード バランシング規則や NAT 規則には触らせたくない、というケースもあります。この場合は Network Contributor だと権限過多なので、カスタム ロールが有効です。

例として、「バックエンド プールの読み書き ＋ NIC からの参加」のみに絞ったカスタム ロールのイメージを示します。

{
  "properties": {
    "roleName": "LB Backend Pool Operator",
    "description": "ロード バランサーのバックエンド プールだけを管理できるロール",
    "permissions": [
      {
        "actions": [
          "Microsoft.Network/loadBalancers/read",
          "Microsoft.Network/loadBalancers/backendAddressPools/read",
          "Microsoft.Network/loadBalancers/backendAddressPools/write",
          "Microsoft.Network/loadBalancers/backendAddressPools/join/action"
        ],
        "notActions": []
      }
    ],
    "assignableScopes": [
      "/subscriptions/<subscription-id>/resourceGroups/RG2"
    ]
  }
}

実際にどのアクションが必要かは構成や運用方式によって変わるため、検証環境で一度試しながら最小権限を見極めるのがおすすめです。

質問3：「Network Contributor」を LB リソース単体に割り当ててもよいのか？

RBAC はリソース グループ単位だけでなく、個別リソース単位にも割り当てることができます。そのため、技術的には「LB1 リソースにだけ Network Contributor を割り当てる」ことも可能です。

ただし、実務上は次の理由から 推奨されないケースが多い です。

理由1：依存リソースとの整合性が取りにくい

LB1 だけに権限を与えた場合、そのユーザーは次のような操作で詰まる可能性があります。

  • 新しいフロントエンド IP 設定を作成するときに、Public IP アドレス（別リソース）を新規作成したいが、その Public IP のリソース グループに権限がないためエラーになる
  • バックエンド プールに VM/NIC を追加したいが、RG1 側の権限がないため、ポータルで VM/NIC 一覧が表示されない

LB1 自体の設定だけ変更できても、その周囲のリソースに手が届かないと、結果的に作業が中途半端になってしまいます。

理由2：運用管理が複雑になる

LB1 にだけロールを割り当てる場合、同じ役割の人に別の LB（LB2, LB3…）を管理させたいとき、LB ごとにロール割り当てを追加しなければならないという問題が発生します。

  • LB が増えるたびにロール割り当てが増え、管理が煩雑になる
  • 「この人はどの LB に権限を持っているのか」を把握しづらい

これに対して、RG2 全体にロールを割り当てておけば、RG2 内に増えた LB も自動的に管理対象になるため、運用管理がシンプルになります。

理由3：権限設計の意図が読み取りにくい

セキュリティ レビューや障害対応の際に、「このユーザーはなぜこの LB にだけ権限を持っているのか？」という問いに答えにくくなることもデメリットです。リソース グループ単位であれば、「この RG のネットワークはこのチームが管理している」といった説明がしやすく、権限設計の意図が読み取りやすくなります。

結論：LB 単体への Network Contributor 割り当ては「技術的には可・運用上は非推奨」

  • 検証環境や一時的な作業であれば LB 単体に割り当てても問題ありません。
  • 本番環境や長期運用では、RG2 全体に Network Contributor を付与し、不要な操作を制限したい場合のみカスタム ロールで調整する方が無難です。

おすすめ構成：RG1 と RG2 それぞれに付与するロール

ここまでの内容を踏まえ、本記事の主題となる「異なるリソース グループ間で LB バックエンドに VM を登録するための現実的な RBAC 構成」をまとめます。

リソース グループ推奨ロール主な目的備考
RG1（VM が存在）Network Contributor Virtual Machine ContributorNIC 経由で LB バックエンドに参加させる ポータルで VM/NIC を一覧表示し、GUI から選択できるようにするIP アドレス直入力のみで運用するなら、Virtual Machine Contributor は不要になる場合もあります。
RG2（LB1 が存在）Network ContributorLB のバックエンド プール構成変更 ロード バランシング規則・NAT 規則・ヘルス プローブの作成と変更LB の設定を「一式任せる」想定なら、Network Contributor を RG 単位で付与するのがシンプルです。

まとめると、RG1 に「Network Contributor + Virtual Machine Contributor」、RG2 に「Network Contributor」を割り当てる構成が、GUI ベースでストレスなく作業でき、かつ実運用でも扱いやすいバランスと言えます。

ロール設計パターン：チーム分割と責務の切り分け

実際の現場では、1 人がすべてを管理するケースよりも、「ネットワークチーム」「アプリチーム」「運用チーム」のように役割が分かれていることが一般的です。ここでは、よくあるパターンをいくつか紹介します。

パターン1：ネットワークチームが LB をフル管理する

  • RG1（アプリ側 RG）
    • アプリチーム：Virtual Machine Contributor またはそれ以上
    • ネットワークチーム：Reader（必要に応じて Network Contributor）
  • RG2（ネットワーク側 RG）
    • ネットワークチーム：Network Contributor
    • アプリチーム：Reader（LB の状態だけ見られればよい場合）

このパターンでは、LB の設定（規則、健康プローブなど）はネットワークチームが一元管理し、アプリチームは VM のライフサイクル管理に集中できます。

パターン2：アプリチームにバックエンド登録だけを任せる

「LB のポート設計や NAT ルールはネットワークチームが担当するが、バックエンドにどの VM をぶら下げるかはアプリチームが自分で切り替えたい」というケースです。

  • RG1：アプリチームに Virtual Machine Contributor（＋ Network Contributor）
  • RG2：
    • ネットワークチーム：Network Contributor
    • アプリチーム：カスタム ロール（バックエンド プールの join のみ許可）

この場合、前述のような「LB Backend Pool Operator」的なロールを作成し、LB 規則や NAT 規則の変更は許可しないように設計します。

パターン3：監視・トラブルシューティング専門の閲覧者

監視チームなど、「設定変更はしないが、LB や VM の状態は確認したい」という担当者には、基本的に Reader ロールを付与します。

  • RG1 / RG2 どちらにも Reader を付与
  • ログ閲覧やアラート確認が必要なら、Log Analytics ワークスペースや Azure Monitor へのアクセスも調整

このように、ロールを組み合わせて チームごとの責務を明確に切り分けると、権限過多による誤操作やセキュリティ リスクを減らせます。

Azure ポータルでの操作イメージと権限エラーの見分け方

実際の操作感と、権限不足のときにどう見えるかも押さえておくと、トラブルシューティングが格段に楽になります。

1. ロール割り当ての確認・設定

  1. Azure ポータルで RG1 を開く
  2. 「アクセス制御 (IAM)」をクリック
  3. 「ロールの割り当てを追加」をクリックし、対象ユーザーまたはサービス プリンシパルに
    • Network Contributor
    • Virtual Machine Contributor
    を選択して付与
  4. 同様に RG2 でも、対象に Network Contributor を割り当てる

2. バックエンド プール追加時の挙動

  • RG1 に十分な権限がある場合
    • LB1 → バックエンド プール → 「+ 追加」から VM/NIC を選ぶ UI が表示される
    • VM 名でフィルタしながら対象を選択できる
  • RG1 の権限が不足している場合
    • VM/NIC の一覧が表示されず、IP アドレスを直接入力する画面しか出てこない
    • あるいは「読み取り権限がありません」といったエラーが表示される
  • RG2 の権限が不足している場合
    • LB1 自体がリソース一覧に表示されない
    • LB1 は見えるが、バックエンド プールの保存時に「許可されていない操作です」といったエラーになる

このように、「どこまで画面が進むか」「どのタイミングでエラーになるか」を観察すると、RG1 側の権限不足なのか、RG2 側の権限不足なのかを切り分けやすくなります。

CLI / PowerShell での RBAC 設定例

最後に、スクリプトでロール割り当てを行う際のイメージも示しておきます。実際の ID 部分は自環境の値に置き換えてください。

Azure CLI でのロール割り当て例

# RG1 に Network Contributor を付与
az role assignment create \
  --assignee <principal-id-or-object-id> \
  --role "Network Contributor" \
  --resource-group RG1

# RG1 に Virtual Machine Contributor を付与
az role assignment create \
  --assignee <principal-id-or-object-id> \
  --role "Virtual Machine Contributor" \
  --resource-group RG1

# RG2 に Network Contributor を付与
az role assignment create \
  --assignee <principal-id-or-object-id> \
  --role "Network Contributor" \
  --resource-group RG2

PowerShell でのロール割り当て例

$principalId = "<principal-id-or-object-id>"

New-AzRoleAssignment `
  -ObjectId $principalId `
  -RoleDefinitionName "Network Contributor" `
  -ResourceGroupName "RG1"

New-AzRoleAssignment `
  -ObjectId $principalId `
  -RoleDefinitionName "Virtual Machine Contributor" `
  -ResourceGroupName "RG1"

New-AzRoleAssignment `
  -ObjectId $principalId `
  -RoleDefinitionName "Network Contributor" `
  -ResourceGroupName "RG2"

スクリプト化しておくことで、新しい環境を作るたびに同じ RBAC 設定を再現できるため、設定漏れや人為的なミスを減らすことができます。

よくあるアンチパターンと注意点

最後に、RBAC 設計で陥りがちなアンチパターンと、その対策を簡単にまとめます。

アンチパターン問題点対策
とりあえず Owner / Contributor を幅広く付与意図しないリソース削除や設定変更のリスク 誰がどこまで権限を持っているのか分からなくなるNetwork Contributor や Virtual Machine Contributor など、役割ごとに適切なロールを選ぶ バックエンド登録のみ必要な場合は、カスタム ロールも検討
LB 単体へのロール割り当て乱用管理対象が増えると RBAC 設定がカオスになる 依存リソースとの整合がとれず、操作エラーの原因になりやすい原則として RG 単位でロールを付与 どうしてもリソース単位にする場合は、期間限定の一時権限として扱う
検証環境と本番環境で RBAC 設計がバラバラ検証では動くのに本番では権限エラーが出る トラブルシューティングが難しくなる本番を意識した RBAC モデルを先に決め、検証環境でも同じモデルをベースにする

まとめ

異なるリソース グループにまたがって VM を Azure Load Balancer のバックエンドに登録する場合、ポイントになるのは次の 3 点です。

  • RG1（VM 側） には、少なくとも
    • Network Contributor
    • Virtual Machine Contributor
    を付与しておくと、ポータルから VM/NIC を選択してバックエンド プールに登録しやすい。
  • RG2（LB 側） には、Network Contributor を付与しておけば、バックエンド プール・ロード バランシング規則・NAT 規則・ヘルス プローブを一通り管理できる。
  • 不要な操作を制限したい場合は、Network Contributor をそのまま使うのではなく、カスタム ロールで必要な Microsoft.Network/* アクションだけを許可するというアプローチが有効。

上記をベースに、自組織のチーム構成や運用ルールに合わせてロール設計を調整すれば、誤操作や権限不足エラーを減らしつつ、最小権限で安全に Azure Load Balancer を運用することができます。

Azure
Azure ロードバランサー RBAC Network Contributor Virtual Machine Contributor

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次