Hosted Agent移行後の403を解消｜専用Entra IDへRBACを再付与する手順

Latest Foundry hosted agentsへ再デプロイした後、Azure Storage、Azure AI Search、Azure Key Vaultなどへのアクセスが403になる場合、最初に確認すべきなのはRBACを付与しているIDです。

Initial previewでは、Hosted AgentがプロジェクトのManaged Identityを共有していました。しかし最新バージョンでは、デプロイ時にエージェントごとの専用Microsoft Entra IDが作成され、そのサービスプリンシパルが下流リソースへアクセスします。したがって、旧プロジェクトManaged Identityの権限を確認するだけでは解決せず、新しいinstance_identity.principal_idへ必要最小限のデータプレーンRBACを再付与する必要があります。(Microsoft Learn)

この記事では、403の原因を切り分け、Hosted Agent専用Entra IDを取得し、Storage、Search、Key Vaultへ正しいRBACを付け直す手順を具体的に解説します。

結論：旧プロジェクトManaged Identityではなく専用Entra IDに付け直す

今回の403は、リソース側の障害ではなく、移行に伴ってHosted Agentの実行主体が変わったことで発生している可能性があります。

対応の流れは次のとおりです。

再デプロイしたHosted Agentのinstance_identity.principal_idを取得する
エージェントが下流リソースで実行する操作を確認する
Storage、Search、Key Vaultなどへ必要最小限のデータプレーンロールを付与する
ロール割り当ての反映を待ってから、Hosted Agent経由で再テストする
403が残る場合は、スコープ、認証方式、ネットワーク制限を確認する

重要なのは、旧Managed Identityのロールをそのまま複製することではありません。移行を機に、実際に必要な読み取り、書き込み、管理操作を整理し、権限を最小化するのが安全です。

今回の移行対象と403が発生する理由

公式の移行案内は、主にInitial previewのHosted Agentを最新バックエンドへ移行するケースを対象としています。

特に、2026年4月より前に、次のライブラリや初期プレビュー向けホスティングAPIを使ってデプロイしたエージェントは確認が必要です。

azure-ai-agentserver-agentframework
azure-ai-agentserver-langgraph
Initial previewのカスタムホスティングAPI

Initial previewのバックエンドは自動移行されません。公式ドキュメントでは、旧バックエンドのサポート期限が2026年8月20日と案内されています。対象エージェントが残っている場合は、再デプロイだけでなく、IDと下流リソースの権限も合わせて移行する必要があります。(Microsoft Learn)

Initial previewと最新バージョンのIDモデルの違い

確認項目	Initial preview	Latest Foundry hosted agents
エージェントの実行主体	プロジェクトのManaged Identity	エージェントごとの専用Entra ID
IDの共有範囲	プロジェクト内で共有	エージェント単位
下流リソースへのアクセス	プロジェクトManaged IdentityへRBACを付与	専用Entra IDへRBACを付与
プロジェクトManaged Identityの主な用途	実行時アクセスにも使用	イメージ取得などの基盤処理
旧権限の引き継ぎ	該当しない	専用IDへ自動では引き継がれない

最新バージョンでは、エージェント専用のMicrosoft Entraサービスプリンシパルが、モデル、ツール、外部サービスへの実行時アクセスに使われます。一方、プロジェクトManaged Identityは、Azure Container Registryからのイメージ取得など、主にホスティング基盤側の処理に使われます。(Microsoft Learn)

たとえば、旧プロジェクトManaged IdentityへStorage Blob Data Readerを付与していても、新しいHosted Agentが提示するアクセストークンの主体は別のオブジェクトIDです。Storage側から見ると、新しい主体には権限がないため403になります。

先に403の発生地点を切り分ける

すべての403が、専用Entra IDへのRBAC不足で発生するわけではありません。どの処理で拒否されているかを確認すると、不要な権限変更を避けられます。

403が発生する場面	主に確認するもの
利用者やアプリがHosted Agentのエンドポイントを呼び出せない	呼び出し元に対するFoundry側の権限
エージェントは起動するが、StorageやSearchのツール実行で失敗する	エージェント専用Entra IDの下流RBAC
デプロイ中にコンテナーイメージを取得できない	プロジェクトManaged IdentityのACR権限
Key Vaultからシークレット値だけ取得できない	Key Vaultのデータプレーンロール
プライベートネットワーク環境だけ失敗する	Firewall、Private Endpoint、DNS
ローカルPCからは成功するがHosted Agentからは失敗する	ローカル利用者とエージェントのIDの違い

Hosted Agentのエンドポイントを呼び出す利用者やアプリには、用途に応じてFoundry Agent ConsumerなどのFoundry側ロールが必要です。一方、エージェント内部からStorageやSearchへアクセスするときは、エージェント専用IDに各サービスのデータプレーン権限が必要です。(Microsoft Learn)

作業前に確認する項目

RBACを変更する前に、次の情報をそろえます。

Foundryアカウント名
プロジェクト名
再デプロイしたHosted Agent名
対象リソースのサブスクリプション、リソースグループ、リソース名
エージェントが実行する操作
ロール割り当てを作成できる管理権限

特に、必要な操作を具体化することが重要です。

「Storageを使う」ではなく、次のように整理します。

Blobを読み取るだけ
Blobを新規作成する
既存Blobを更新または削除する
Searchインデックスを検索するだけ
Searchへ文書を追加する
インデックスやインデクサー自体を作成する
Key Vaultのシークレット値を読む
シークレットを作成または更新する

ロール割り当てを作成するには、対象スコープでMicrosoft.Authorization/roleAssignments/writeが必要です。通常、OwnerまたはRole Based Access Control Administratorなどが該当します。一般的なContributorだけでは、リソースを編集できてもRBACを追加できません。

また、プロジェクトスコープのFoundry Project ManagerはHosted Agentのデプロイには使えますが、外部のStorageやKey Vaultへ自由にロールを付与できる権限ではありません。(Microsoft Learn)

Hosted Agent専用Entra IDを取得する

最新のHosted Agentでは、エージェント情報にinstance_identityが含まれています。その中のprincipal_idが、下流リソースのRBAC割り当て先となるオブジェクトIDです。

Azure CLIで取得する

Azure CLIへログインし、Foundryのアカウント名、プロジェクト名、エージェント名を指定します。

az login

ACCOUNT_NAME="<foundry-account-name>"
PROJECT_NAME="<project-name>"
AGENT_NAME="<hosted-agent-name>"

BASE_URL="https://${ACCOUNT_NAME}.services.ai.azure.com/api/projects/${PROJECT_NAME}"
RESOURCE="https://ai.azure.com"

AGENT_IDENTITY=$(az rest \
  --method GET \
  --url "${BASE_URL}/agents/${AGENT_NAME}?api-version=v1" \
  --resource "${RESOURCE}" \
  --query "instance_identity.principal_id" \
  --output tsv)

if [ -z "$AGENT_IDENTITY" ]; then
  echo "Hosted Agentのprincipal_idを取得できませんでした。" >&2
  exit 1
fi

echo "$AGENT_IDENTITY"

az restでFoundryのデータプレーンAPIを呼び出す際は、--resource "https://ai.azure.com"を省略しないでください。異なるリソース向けのトークンが使われると、API呼び出し自体が認証エラーになります。 (Microsoft Learn)

PowerShellで取得する

WindowsやAzure Cloud ShellのPowerShellを使う場合は、次のように取得できます。

az login

$AccountName = "<foundry-account-name>"
$ProjectName = "<project-name>"
$AgentName = "<hosted-agent-name>"

$BaseUrl = "https://${AccountName}.services.ai.azure.com/api/projects/${ProjectName}"
$Resource = "https://ai.azure.com"

$AgentIdentity = az rest `
  --method GET `
  --url "${BaseUrl}/agents/${AgentName}?api-version=v1" `
  --resource $Resource `
  --query "instance_identity.principal_id" `
  --output tsv

if ([string]::IsNullOrWhiteSpace($AgentIdentity)) {
    throw "Hosted Agentのprincipal_idを取得できませんでした。エージェント名とデプロイ状態を確認してください。"
}

$AgentIdentity

取得結果は、表示名ではなくGUID形式のオブジェクトIDです。RBAC割り当てでは、この値を--assignee-object-idへ指定します。

デプロイ直後で値が取得できない場合は、エージェントの状態がactiveになっているか確認してください。エージェント名、プロジェクト名、アカウント名の取り違えにも注意が必要です。(Microsoft Learn)

下流リソースごとに最小権限を選ぶ

AzureのRBACでは、リソースを作成・設定するコントロールプレーン権限と、Blobやシークレットなどの内容へアクセスするデータプレーン権限が分かれています。

ContributorやReaderを付与しただけでは、Blobの読み書きやKey Vaultのシークレット値取得ができないことがあります。Hosted Agentには、実際の処理に対応するデータプレーンロールを選びます。

対象サービス	エージェントが行う操作	主な最小権限候補
Azure Storage	Blobの一覧表示、読み取り	`Storage Blob Data Reader`
Azure Storage	Blobの作成、更新、削除	`Storage Blob Data Contributor`
Azure AI Search	インデックスの検索	`Search Index Data Reader`
Azure AI Search	文書の追加、更新、削除	`Search Index Data Contributor`
Azure AI Search	インデックスやインデクサーの作成・管理	`Search Service Contributor`
Azure Key Vault	シークレット値の取得	`Key Vault Secrets User`
Azure Key Vault	シークレットの作成、更新、削除	`Key Vault Secrets Officer`
Azure Key Vault	鍵を使った暗号化や復号	`Key Vault Crypto User`

Azure AI SearchのSearch Service Contributorは、インデックスやインデクサーなどの検索オブジェクトを管理するためのロールです。このロールだけでは、インデックス内の文書を検索したり、文書を投入したりできません。管理とデータ操作の両方が必要な場合は、対応するロールを組み合わせます。(Microsoft Learn)

Key VaultのKey Vault Readerは、シークレットの名前や属性などのメタデータを参照するためのロールです。シークレット値そのものを取得するにはKey Vault Secrets Userなどが必要です。また、Key Vault Contributorは主にコンテナーとしてのKey Vaultを管理するコントロールプレーンロールであり、シークレット値を読み取る権限ではありません。(Microsoft Learn)

専用Entra IDへRBACを付け直す

基本形は次のとおりです。

az role assignment create \
  --assignee-object-id "$AGENT_IDENTITY" \
  --assignee-principal-type ServicePrincipal \
  --role "<role-name>" \
  --scope "<target-resource-scope>"

--assignee-object-idと--assignee-principal-type ServicePrincipalを明示することで、Azure CLIによるMicrosoft Graphの名前検索を避けられます。デプロイ直後のサービスプリンシパルや、Graph参照権限が制限された環境でも、割り当てを安定させやすくなります。(Microsoft Learn)

Azure Storageへ付与する

Blobを読み取るだけなら、ストレージアカウント全体ではなく、対象コンテナーへStorage Blob Data Readerを付与します。

SUBSCRIPTION_ID="<subscription-id>"
RESOURCE_GROUP="<storage-resource-group>"
STORAGE_ACCOUNT="<storage-account-name>"
CONTAINER_NAME="<container-name>"

STORAGE_SCOPE="/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Storage/storageAccounts/${STORAGE_ACCOUNT}/blobServices/default/containers/${CONTAINER_NAME}"

az role assignment create \
  --assignee-object-id "$AGENT_IDENTITY" \
  --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Reader" \
  --scope "$STORAGE_SCOPE"

Blobの作成、更新、削除も必要な場合は、ロールをStorage Blob Data Contributorへ変更します。

az role assignment create \
  --assignee-object-id "$AGENT_IDENTITY" \
  --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Contributor" \
  --scope "$STORAGE_SCOPE"

複数のコンテナーへアクセスさせる必要がある場合は、コンテナーごとに割り当てるか、運用上妥当であればストレージアカウントスコープへ広げます。最初からサブスクリプションやリソースグループ全体へ付与するのは避けるべきです。(Microsoft Learn)

Azure AI Searchへ付与する

検索クエリを実行するだけなら、SearchサービスへSearch Index Data Readerを付与します。

SEARCH_RESOURCE_GROUP="<search-resource-group>"
SEARCH_SERVICE="<search-service-name>"

SEARCH_SCOPE="/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${SEARCH_RESOURCE_GROUP}/providers/Microsoft.Search/searchServices/${SEARCH_SERVICE}"

az role assignment create \
  --assignee-object-id "$AGENT_IDENTITY" \
  --assignee-principal-type ServicePrincipal \
  --role "Search Index Data Reader" \
  --scope "$SEARCH_SCOPE"

Hosted Agentが文書を追加、更新、削除する場合は、Search Index Data Contributorを付与します。

az role assignment create \
  --assignee-object-id "$AGENT_IDENTITY" \
  --assignee-principal-type ServicePrincipal \
  --role "Search Index Data Contributor" \
  --scope "$SEARCH_SCOPE"

エージェントがインデックス、データソース、スキルセット、インデクサーなどを作成する場合は、さらにSearch Service Contributorが必要です。

az role assignment create \
  --assignee-object-id "$AGENT_IDENTITY" \
  --assignee-principal-type ServicePrincipal \
  --role "Search Service Contributor" \
  --scope "$SEARCH_SCOPE"

Azure AI Search側では、Microsoft Entra IDによるデータプレーンアクセスを利用できるよう、APIアクセス制御が「ロールベース」または「APIキーとロールベース」の構成になっている必要があります。APIキーのみの構成では、正しいRBACを付与してもEntraトークンによるアクセスは成功しません。(Microsoft Learn)

Azure Key Vaultへ付与する

シークレット値を読み取るだけなら、Key VaultスコープへKey Vault Secrets Userを付与します。

KEYVAULT_RESOURCE_GROUP="<key-vault-resource-group>"
KEYVAULT_NAME="<key-vault-name>"

KEYVAULT_SCOPE="/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${KEYVAULT_RESOURCE_GROUP}/providers/Microsoft.KeyVault/vaults/${KEYVAULT_NAME}"

az role assignment create \
  --assignee-object-id "$AGENT_IDENTITY" \
  --assignee-principal-type ServicePrincipal \
  --role "Key Vault Secrets User" \
  --scope "$KEYVAULT_SCOPE"

シークレットの登録や更新も行う場合は、Key Vault Secrets Officerを検討します。

az role assignment create \
  --assignee-object-id "$AGENT_IDENTITY" \
  --assignee-principal-type ServicePrincipal \
  --role "Key Vault Secrets Officer" \
  --scope "$KEYVAULT_SCOPE"

Key Vaultが従来のアクセスポリシー方式で動作している場合、Azure RBACのロールを追加してもシークレットのデータアクセスには反映されません。まず、Key Vaultのアクセス許可モデルが「Azureロールベースのアクセス制御」になっているか確認してください。(Microsoft Learn)

ロール割り当てを確認する

付与後は、対象スコープに正しいオブジェクトIDとロールが登録されているか確認します。

az role assignment list \
  --assignee "$AGENT_IDENTITY" \
  --scope "$STORAGE_SCOPE" \
  --output table

SearchとKey Vaultについても同様に確認します。

az role assignment list \
  --assignee "$AGENT_IDENTITY" \
  --scope "$SEARCH_SCOPE" \
  --output table

az role assignment list \
  --assignee "$AGENT_IDENTITY" \
  --scope "$KEYVAULT_SCOPE" \
  --output table

確認する項目は次の3点です。

PrincipalIdが取得したinstance_identity.principal_idと一致している
RoleDefinitionNameが必要なデータプレーンロールになっている
Scopeが対象リソースを含んでいる

リソースグループなどの親スコープで割り当てている場合は、Azureポータルの「アクセス制御（IAM）」から継承されたロールも確認します。

RBACの反映後にHosted Agentから再テストする

Azure RBACの変更は即時反映されるとは限りません。通常は数分で反映されますが、Azure Storageでは反映まで最大30分程度かかる場合があります。デプロイ直後の専用Entra IDは、Microsoft Entra ID内での複製に時間がかかることもあります。(Microsoft Learn)

テストは、管理者のローカルPCではなく、実際のHosted Agent経由で行います。

たとえばStorageの場合、管理者がAzure CLIでBlobを取得できても、Hosted Agentの専用IDに権限があることの証明にはなりません。次のような影響の小さい処理で確認します。

StorageのコンテナーまたはBlobを1件読み取る
Searchへ件数を限定した検索を実行する
Key Vaultから検証用シークレットを取得する
書き込みが必要な場合は、専用のテストデータを作成して削除する

Key Vaultのシークレット値をログへ出力するのは避けてください。取得の成否だけを記録するか、値をマスクして確認します。

Hosted Agentの実行ログは、利用しているデプロイ方法に応じてFoundry側の監視画面やazd ai agent monitorなどから確認できます。403を返したサービス名、要求先、ステータスコード、認証エラーの詳細を確認すると、RBACとネットワークのどちらが原因か判断しやすくなります。(Microsoft Learn)

RBACを付け直しても403が消えない場合

古いIDや別のエージェントへ付与している

最も多いのは、次の取り違えです。

旧プロジェクトManaged Identityへ付与している
移行前のHosted AgentのIDへ付与している
開発環境と本番環境のエージェントを取り違えている
同名のエージェントが別プロジェクトに存在している
再作成前のオブジェクトIDをCI/CD変数に残している

表示名では判断せず、対象エージェントのAPIから取得したinstance_identity.principal_idと、IAM画面のPrincipal IDを照合します。

コントロールプレーンロールしか付いていない

次のような割り当てでは、下流データを操作できない場合があります。

付与したロール	できない可能性がある操作
`Contributor`	BlobデータやKey Vaultシークレット値の読み取り
`Storage Account Contributor`	Blobデータの読み書き
`Search Service Contributor`	インデックス文書の検索、投入
`Key Vault Contributor`	シークレット値、鍵、証明書のデータ操作
`Key Vault Reader`	シークレット値の取得

403が出たサービスについて、データプレーン用ロールが付与されているかを確認します。(Microsoft Learn)

スコープが対象リソースを含んでいない

よくある例は、同じ名前のリソースを取り違えているケースです。

別のサブスクリプションへ付与した
開発用Storageへ付与した
別のリソースグループを指定した
Blobコンテナー名を間違えた
Searchサービスを複数環境で取り違えた
Key Vaultを旧環境と新環境で取り違えた

ロール名だけでなく、完全なリソースIDを比較してください。

Azure AI SearchのRBAC認証が有効になっていない

SearchサービスがAPIキーのみを許可する設定の場合、Entra IDのロール割り当てだけではアクセスできません。

Searchサービスの「キー」または「APIアクセス制御」に相当する設定を確認し、Microsoft Entra IDのロールベース認証が許可されていることを確認します。(Microsoft Learn)

Key Vaultがアクセスポリシー方式になっている

Key Vaultのアクセス許可モデルがアクセスポリシー方式の場合、Azure RBACのデータプレーンロールは使用されません。

本番環境でRBAC方式へ切り替える場合は、既存アプリや運用ツールへの影響を確認し、必要な権限を移行してから変更します。方式を確認せずに切り替えると、既存システムまでKey Vaultへアクセスできなくなる可能性があります。(Microsoft Learn)

ツールや接続設定が別の認証方式を使っている

最新Hosted Agentの標準的な実行主体はエージェント専用IDですが、ツールや接続の構成によっては、次の方式が明示されている場合があります。

エージェント専用ID
プロジェクトManaged Identity
APIキー
接続に保存された資格情報
カスタム認証処理

たとえば、接続設定がプロジェクトManaged Identityを使う構成のままなら、エージェント専用IDへロールを付与しても、その接続の403は解消しません。MCPやA2A、独自ツールを利用している場合は、接続の認証方式と、実際にトークンを取得している主体を確認します。(Microsoft Learn)

カスタムコードでアクセストークンを取得している場合は、トークンの対象リソースも確認してください。代表的な対象リソースは次のとおりです。

サービス	トークンの対象リソース例
Azure Storage	`https://storage.azure.com`
Azure Key Vault	`https://vault.azure.net`
Microsoft Foundryデータプレーン	`https://ai.azure.com`

正しいIDにRBACが付いていても、別サービス向けのトークンを送信すれば認証または認可に失敗します。(Microsoft Learn)

FirewallやPrivate Endpointで拒否されている

RBACは「誰がアクセスできるか」を制御しますが、FirewallやPrivate Endpointは「どこから接続できるか」を制御します。正しいRBACを付与しても、ネットワーク経路が許可されていなければ403は残ります。

次の点を確認します。

Storageのネットワークアクセス設定
Searchサービスのパブリックネットワークアクセス設定
Key VaultのFirewall設定
Private Endpointの接続状態
Private DNSゾーンとのリンク
Hosted Agent実行環境からの名前解決
必要なサブネットや送信元が許可されているか

特に、ローカルPCからは成功し、Hosted Agentからだけ403になる場合は、IP制限やプライベート接続を疑います。RBACの追加だけでFirewall制限を回避することはできません。(Microsoft Learn)

`PrincipalNotFound`が表示される

エージェントをデプロイした直後にロール割り当てを作成すると、専用サービスプリンシパルがMicrosoft Entra ID全体へ複製される前で、PrincipalNotFoundになる場合があります。

対処方法は次のとおりです。

数分待ってから再実行する
表示名ではなくオブジェクトIDを使う
--assignee-object-idを使う
--assignee-principal-type ServicePrincipalを明示する

CI/CDでは、ロール割り当て処理に短い再試行を組み込むと安定します。(Microsoft Learn)

CI/CDでRBACの付け忘れを防ぐ

Hosted Agentの専用Entra IDはデプロイ後に取得する必要があります。そのため、デプロイとRBAC割り当てを一つの固定テンプレートだけで完結させようとすると、IDの受け渡しで失敗しやすくなります。

実務では、次の順序に分けると管理しやすくなります。

Hosted Agentをデプロイする
エージェントがactiveになるまで確認する
instance_identity.principal_idをAPIから取得する
下流リソースごとにRBACを作成する
ロール割り当て結果を一覧で確認する
Hosted Agentからスモークテストを実行する
成功後に本番トラフィックを切り替える

専用Entra IDを設定ファイルへ手入力して固定するのではなく、デプロイ後に毎回APIから取得する構成が安全です。エージェントの新規作成や再作成が行われても、現在のオブジェクトIDを使用できます。最新Hosted Agentでは専用IDがエージェント単位で作成されるため、外部リソースへのカスタムRBACはデプロイ後の工程として管理する必要があります。(Microsoft Learn)

旧プロジェクトManaged Identityの権限はすぐ削除しない

専用Entra IDへの移行が完了しても、プロジェクトManaged Identityのロールを一括削除するのは避けます。

プロジェクトManaged Identityは、引き続き次の用途で使われる可能性があります。

Azure Container Registryからのイメージ取得
Foundryのホスティング基盤処理
明示的にプロジェクトManaged Identityを使う接続
まだ移行していない旧Hosted Agent
同じプロジェクト内の別エージェントやツール

まず、新しいHosted Agentの動作確認を完了します。その後、旧Managed Identityへ付与されている下流リソースのロールを棚卸しし、利用者がないことを確認できたものだけを削除します。(Microsoft Learn)

移行時の確認チェックリスト

Hosted Agentを最新バージョンへ再デプロイした
エージェントの状態がactiveになっている
instance_identity.principal_idを取得した
旧プロジェクトManaged Identityと専用IDを区別した
StorageにはBlobデータ用ロールを付与した
Searchには検索・文書更新・管理操作に応じたロールを付与した
Key Vaultにはシークレットや鍵のデータプレーンロールを付与した
ロールのスコープを必要なリソースへ限定した
Searchのロールベース認証設定を確認した
Key Vaultのアクセス許可モデルを確認した
Firewall、Private Endpoint、DNSを確認した
RBACの反映時間を考慮して再テストした
Hosted Agent自身の実行ログで成功を確認した
旧Managed Identityの権限を削除する前に利用状況を確認した

まとめ

Latest Foundry hosted agentsへの移行後にStorage、Search、Key Vaultなどで403が発生した場合は、旧プロジェクトManaged Identityの権限を増やすのではなく、再デプロイしたエージェントのinstance_identity.principal_idを確認します。

そのうえで、次の順序で対応します。

専用Entra IDを取得する
エージェントが実行する操作を特定する
必要なデータプレーンロールだけを付与する
スコープ、認証方式、ネットワーク設定を確認する
Hosted Agent経由で動作テストする

今回の移行は、単なる再デプロイではなく、実行時IDの分離を伴う変更です。下流リソースのRBACをエージェント単位で管理することで、403を解消できるだけでなく、複数エージェント間の権限分離と最小権限化も実現できます。

この記事を書いた人

佐藤健司

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

Hosted Agent移行後の403を解消｜専用Entra IDへRBACを再付与する手順

結論：旧プロジェクトManaged Identityではなく専用Entra IDに付け直す

今回の移行対象と403が発生する理由

Initial previewと最新バージョンのIDモデルの違い

先に403の発生地点を切り分ける

作業前に確認する項目

Hosted Agent専用Entra IDを取得する

Azure CLIで取得する

PowerShellで取得する

下流リソースごとに最小権限を選ぶ

専用Entra IDへRBACを付け直す

Azure Storageへ付与する

Azure AI Searchへ付与する

Azure Key Vaultへ付与する

ロール割り当てを確認する

RBACの反映後にHosted Agentから再テストする

RBACを付け直しても403が消えない場合

古いIDや別のエージェントへ付与している

コントロールプレーンロールしか付いていない

スコープが対象リソースを含んでいない

Azure AI SearchのRBAC認証が有効になっていない

Key Vaultがアクセスポリシー方式になっている

ツールや接続設定が別の認証方式を使っている

FirewallやPrivate Endpointで拒否されている

`PrincipalNotFound`が表示される

CI/CDでRBACの付け忘れを防ぐ

旧プロジェクトManaged Identityの権限はすぐ削除しない

移行時の確認チェックリスト

まとめ

この記事を書いた人

コメント

コメントするコメントをキャンセル

Hosted Agent移行後の403を解消｜専用Entra IDへRBACを再付与する手順

結論：旧プロジェクトManaged Identityではなく専用Entra IDに付け直す

今回の移行対象と403が発生する理由

Initial previewと最新バージョンのIDモデルの違い

先に403の発生地点を切り分ける

作業前に確認する項目

Hosted Agent専用Entra IDを取得する

Azure CLIで取得する

PowerShellで取得する

下流リソースごとに最小権限を選ぶ

専用Entra IDへRBACを付け直す

Azure Storageへ付与する

Azure AI Searchへ付与する

Azure Key Vaultへ付与する

ロール割り当てを確認する

RBACの反映後にHosted Agentから再テストする

RBACを付け直しても403が消えない場合

古いIDや別のエージェントへ付与している

コントロールプレーンロールしか付いていない

スコープが対象リソースを含んでいない

Azure AI SearchのRBAC認証が有効になっていない

Key Vaultがアクセスポリシー方式になっている

ツールや接続設定が別の認証方式を使っている

FirewallやPrivate Endpointで拒否されている

PrincipalNotFoundが表示される

CI/CDでRBACの付け忘れを防ぐ

旧プロジェクトManaged Identityの権限はすぐ削除しない

移行時の確認チェックリスト

まとめ

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

`PrincipalNotFound`が表示される

コメントするコメントをキャンセル