Azure FoundryのRBAC Owner参照挙動をクラシックロール併存環境で検証(2026/7/8 時点)
kagiyama_yVisualStudio由来のAzureサブスクを長く使っていると、クラシック時代のロールがそのまま残っている場面がある。AccountAdminとRBACOwnerが分かれたまま維持されているケースは珍しくなく、現在の利用者が想定している権限と、Foundryが実際に参照する権限が一致しないことがある。今回は、その状態がどう影響するかを、手元の環境で確認した内容としてまとめておく。
VS由来のサブスクでは、課金管理のAccountAdminが残り続ける一方で、リソース操作はRBACOwnerが基準になる。古いMSDNの紐づけが残っている環境では、RBACOwnerが過去のゲストアカウントのままになっていることがあり、利用者がAccountAdminであってもFoundryの権限チェックではOwnerとして扱われない。
FoundryはRBACOwnerだけを参照するため、クラシック側の権限がどれだけ強くても、RBACOwnerが別アカウントなら操作が止まる。これは構造的な挙動で、ロールの履歴が長いVS由来サブスクでは特に表面化しやすい。
この状態を解消するには、現在RBACOwnerを持っているアカウントでログインし、Subscriptions→IAM→Ownerに自分を追加する。これでFoundryが参照する権限が揃う。もし既存Ownerがログイン不能なら、ユーザー側で修復できる範囲を超えるため、サポートによる再構成が必要になる。
クラシックロールとRBACが分離したまま残ることがあり、FoundryのようにRBACを厳密に参照するサービスではその差異が直接挙動に出る傾向に。RBACOwnerが自分でない場合、操作が止まるのは仕方ないというか自然で、Owner追加によって整合が取れる。
長期利用の環境では、ロールの棚卸しを事前に行うことで、FoundryやEntraの権限チェックでの不一致を避けられる。結論としてはロール履歴が権限判定に影響大ありということです。
