3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@har1101

別アカウントに存在するMCPサーバーをAgentCore Registryに集約したい〜IAM認証編〜

3
Posted at

tl;dr

  • AアカウントのMCPサーバー/A2AエージェントをBアカウントのAgentCore Registryに登録することは可能
  • その際、手法としてはURL同期と手動設定の2つが存在する
    • 本ブログではURL同期のみを試してみる
  • 基本的にはまずURL同期を試すのが良いが、権限設定が少し大変
  • 登録後の実運用どうすればいいの…？

はじめに

こんにちは、ふくちと申します。
今回はAgentCore Registryをマルチアカウント前提で使う場合の話をしていきます。

AgentCore Registryそのものについては以下のブログなどをご参照ください。

マルチアカウントでのRegistryアーキテクチャ

URL同期を用いる際は、恐らく以下のような形になるのではないかなと思っています。
image.png

  • ワークロードアカウント側の登録者
    1. 中央アカウントの登録用IAMロールをAssume Role
    2. 上記登録用IAMロールを用いて、中央アカウント側のRegistryに登録申請を出す
  • 中央アカウント側の管理者
    1. Registryに自動で登録されるMCPサーバー/エージェントの情報を確認し、承認/拒否する

ざっくり解説するとこれだけです。が、本格的にやろうとすると細かく権限設定が必要になったり、申請のパイプラインを用意したり…ということが必要になるのでそのあたりは難しいだろうなと思っています。

ただこのブログではまず基本的な形や流れを解説していこうと思います。

1. 中央アカウントでRegistryを作成する

コンソール上からRegistryを作っていきます。赤枠部分です。
image.png

Search API認証はIAMを選択します。これはこのRegistryへアクセスする際に、IAM認証を用いるかJWT認証を用いるか、というところを選択しています。
image.png

以降の作業で、このRegistry内にレコードと言う形でMCPサーバーを登録していきます。
image.png

2.ワークロードアカウントでAgentCore Gatewayを作成する

続いてはワークロードアカウント側の作業で、Gatewayを作成します。赤枠部分です。
(その隣のA2Aサーバーは今回作成しません)
image.png

インバウンド認証はIAMを選択し、ターゲットはひとまず公式が用意してくれているTavilyを選択しています。
image.png

image.png

その後、Gatewayにリソースベースのポリシーを設定します。

Gatewayのリソースベースのポリシー
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowCentralRegistrySyncRoleInvokeGateway",
    "Effect": "Allow",
    "Principal": { "AWS": "<中央アカウントのcentral-registry-sync-roleのARN>" },
    "Action": "bedrock-agentcore:InvokeGateway",
    "Resource": "<ワークロードアカウントのAgentCore Gateway ARN>"
  }]
}

3. 中央アカウントでIAMロールとIAMポリシーを作成する

ここでは以下2種類のIAMロールとポリシーを作成します。

  • AgentCore Registryに紐づけるもの
  • ワークロードアカウントアカウントからのAssume Roleを受け付けるもの

image.png

3.1 AgentCore Registryに紐づけるIAMロール/ポリシー

IAMポリシーは以下で新規作成します。

central-registry-sync-policy
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "bedrock-agentcore:InvokeGateway",
    "Resource": "<ワークロードアカウントのAgentCore Gateway ARN>"
  }]
}

IAMロールにおいて、信頼されたエンティティは以下のように設定します。
紐づけるIAMポリシーは上記のcentral-registry-sync-policyを選択します。

central-registry-sync-roleの信頼されたエンティティ
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "bedrock-agentcore.amazonaws.com" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "aws:SourceAccount": "<中央アカウントのアカウントID>" }
    }
  }]
}

3.2 ワークロードアカウントからのAssume Roleを受け付けるIAMロール/ポリシー

IAMポリシーは以下で新規作成します。最小権限にはなっていませんが悪しからず。

central-publisher-policy
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListRegistries",
      "Effect": "Allow",
      "Action": "bedrock-agentcore:ListRegistries",
      "Resource": "*"
    },
    {
      "Sid": "GetRegistry",
      "Effect": "Allow",
      "Action": "bedrock-agentcore:GetRegistry",
      "Resource": "<中央アカウントのRegistry Arn>"
    },
    {
      "Sid": "CreateAndListRegistryRecords",
      "Effect": "Allow",
      "Action": [
        "bedrock-agentcore:CreateRegistryRecord",
        "bedrock-agentcore:ListRegistryRecords"
      ],
      "Resource": "<中央アカウントのRegistry Arn>"
    },
    {
      "Sid": "ManageDraftRegistryRecords",
      "Effect": "Allow",
      "Action": [
        "bedrock-agentcore:GetRegistryRecord",
        "bedrock-agentcore:UpdateRegistryRecord",
        "bedrock-agentcore:DeleteRegistryRecord",
        "bedrock-agentcore:SubmitRegistryRecordForApproval"
      ],
      "Resource": "<中央アカウントのRegistry Arn>/record/*"
    },
    {
      "Sid": "PassSyncRoleForIamSync",
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::<中央アカウントID>:role/central-registry-sync-role",
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "bedrock-agentcore.amazonaws.com"
        },
        "ArnLike": {
          "iam:AssociatedResourceArn": "<中央アカウントのRegistry Arn>/record/*"
        }
      }
    }
  ]
}

IAMロールにおいて、信頼されたエンティティは以下のように設定します。
紐づけるIAMポリシーは上記のcentral-publisher-policyを選択します。

central-publisher-roleの信頼されたエンティティ
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::<ワークロードアカウントID>:role/workload-assume-central-publisher-role"
    },
    "Action": "sts:AssumeRole"
  }]
}

4. ワークロードアカウントでIAMロールとIAMポリシーを作成する

先程作成した中央アカウントの登録用IAMロールをAssume Roleするためのものです。
本来ならCIに組み込んだりして自動化するためのものになるのかなと思っていますが、ひとまずこんな漢字で…
image.png

assume-central-publisher-policy
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::<中央アカウントID>:role/central-publisher-role"
        }
    ]
}

IAMロールの信頼されたエンティティは以下を設定します。

workload-assume-central-publisher-role
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {
                "AWS": "<ワークロードアカウントID>"
            },
            "Condition": {}
        }
    ]
}

5. 実際に申請→承認までやってみる

ここからは先程の構成図に沿って、同じ流れを試してみます。
image.png

まず、ワークロードアカウント側の登録者の作業です。
自作したGatewayを、中央アカウントのRegistryに登録申請を出します。

続いて中央アカウント側の管理者が、その申請を確認して承認します。

5.1 ワークロードアカウント側の作業

本来であればもう少し自動化するものだと思いますが、ここではCLIで実施していきます。
事前準備としてaws loginやaws sso loginで、ワークロードアカウント側の登録者として認証しておいてください。

そこから一気に登録までやってみましょう。

ターミナル
# ワークロードアカウントのIAMユーザーやSSOログイン認証情報がセットされていることを確認する
aws sts get-caller-identity

# 変数をセットする
export REGION=ap-northeast-1
export WORKLOAD_REGISTER_ROLE_ARN='arn:aws:iam::<ワークロードアカウントID>:role/workload-assume-central-publisher-role'
export PUBLISHER_ROLE_ARN='arn:aws:iam::<中央アカウントID>:role/central-publisher-role'

# まずはワークロードアカウントの登録用ロールへスイッチ
read AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN < <(
  aws sts assume-role \
    --role-arn "$WORKLOAD_REGISTER_ROLE_ARN" \
    --role-session-name workload-registry-register-test \
    --region "$REGION" \
    --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' \
    --output text
)
export AWS_ACCESS_KEY_ID
export AWS_SECRET_ACCESS_KEY
export AWS_SESSION_TOKEN

# ワークロードアカウントの登録用ロールになっていることを確認
aws sts get-caller-identity

# ワークロードアカウントの登録用ロールから、中央アカウントの登録用ロールにAssumeRole
read AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN < <(
  aws sts assume-role \
    --role-arn "$PUBLISHER_ROLE_ARN" \
    --role-session-name central-registry-publisher-test \
    --region "$REGION" \
    --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' \
    --output text
)
export AWS_ACCESS_KEY_ID
export AWS_SECRET_ACCESS_KEY
export AWS_SESSION_TOKEN

# 中央アカウントの登録用ロールになっていることを確認
aws sts get-caller-identity

# 中央アカウントのRegistryへGatewayを登録する申請を出す
export REGISTRY_ID='arn:aws:bedrock-agentcore:ap-northeast-1:<中央アカウントID>:registry/<registry-id>'
export RECORD_NAME='example-gateway-mcp'
export MCP_URL='https://<gateway-mcp-endpoint>'
export SYNC_ROLE_ARN='arn:aws:iam::<中央アカウントID>:role/central-registry-sync-role'

# IAM同期の設定を別途切り出す
cat > /tmp/registry-sync-config.json <<EOF
{
  "fromUrl": {
    "url": "$MCP_URL",
    "credentialProviderConfigurations": [
      {
        "credentialProviderType": "IAM",
        "credentialProvider": {
          "iamCredentialProvider": {
            "roleArn": "$SYNC_ROLE_ARN",
            "service": "bedrock-agentcore",
            "region": "$REGION"
          }
        }
      }
    ]
  }
}
EOF

# Registryへレコードを作成する
RECORD_ARN=$(aws bedrock-agentcore-control create-registry-record \
  --registry-id "$REGISTRY_ID" \
  --name "$RECORD_NAME" \
  --description "MCP server registered via workload role and central publisher role" \
  --descriptor-type MCP \
  --synchronization-type URL \
  --synchronization-configuration file:///tmp/registry-sync-config.json \
  --region "$REGION" \
  --query 'recordArn' \
  --output text)
echo "$RECORD_ARN"

# 作成したレコードを確認する。"status": "DRAFT"になっていればOK
aws bedrock-agentcore-control get-registry-record \
  --registry-id "$REGISTRY_ID" \
  --record-id "$RECORD_ARN" \
  --region "$REGION" \
  --query '{recordId:recordId, status:status, statusReason:statusReason}'

ここで一度マネジメントコンソールでも確認してみます。ドラフトが作成されていますね。
image.png

--synchronization-type URLを選択しているので、マネージドに同期してくれるモードになっています。
このとき、申請したMCPサーバーに設定されているツールスキーマなどが自動で入力されています。
また、先ほど設定した同期用IAMロールがきちんと設定されているのがわかると思います。
image.png

そして次は、このレコードを承認してもらうよう申請してみます。
マネコン上だと以下のように出ていますが、実際の申請を見越して先ほどと同じようにCLIにします。
image.png

ターミナル
# 承認依頼を送信する。"status": "PENDING_APPROVAL"に更新されればOK。
aws bedrock-agentcore-control submit-registry-record-for-approval \
  --registry-id "$REGISTRY_ID" \
  --record-id "$RECORD_ARN" \
  --region "$REGION" \
  --query '{recordId:recordId, status:status, updatedAt:updatedAt}'

またコンソールから確認してみます。同じようにステータスが承認待ちになっていると思います。
ここまでがワークロードアカウント側の人の作業です。
image.png

5.2 中央アカウント側の作業

あとは承認/否認するだけです。ここではマネコン上で承認してみます。
更新ステータスから承認を押します。
image.png

承認理由は任意です。本番ではもっとちゃんとした内容を入力しましょう。
image.png

すると、承認済みになりました。ここまでくればOKです。
余談ですが、一度承認した後でやっぱり拒否！みたいなのもできるみたいです。
image.png

実際にレコードを検索してみると、登録したMCPサーバーを確認することができました！
image.png

ただこれ、実運用を見据えるとどこのアカウントにあるとかがわかった方が良い気もするんですが…そこは組織側で上手いこと連携してね、ってことなんですかね。

5.3 おまけ：拒否してみる

一度承認した後、拒否してみました。
image.png
↓
image.png

ちゃんと検索対象からいなくなっていますね。
image.png

5.4 おまけ：非推奨にしてみる

非推奨、とだけ聞くと「一応まだ使えるけど、もう古いから別の使ったほうがいいよ〜」みたいなニュアンスに聞こえますよね。

ただRegistryの非推奨は事実上の廃止です。一度このステータスに変更すると、もう使うことも編集することもできません。検索対象としては残るらしいので、監査があるから残さないといけないけど使わせたくない、みたいな場合に使うものなのかなと思っています。

image.png
↓
image.png
↓
image.png

非推奨は最終状態であり、レコードがこの状態になると、編集したり、他の状態に移行したりすることはできません。監査目的でListRegistryRecords APIおよびGetRegistryRecord APIを使用してレコードを検索することはできますが、非推奨状態を解除することはできません。

まとめと、実運用を見据えた課題

ここまででざっくりと手順を解説してきました。
ただ、現実問題ここまで綺麗に運用できるかと言われると……うーんというのがあると思います。私も多分無理です。

また、先ほども少し書いたのですが、Registryだけだと「こんなMCPサーバー/エージェントが組織内にある」ことがわかっても、それを使うためには別途やり取りが必要なんですよね。

例えばこんな感じになるのかなと。

  • A部署側の人が「このMCPサーバー使いたいんだけど〜」と中央アカウントの管理者に伝える
  • 中央アカウントの管理者が「このMCPサーバーはB部署管理か…確認してみますね」と返答する
  • 中央アカウントの管理者が「B部署さん、A部署さんにもこのMCPサーバー使わせてあげてもいいですか？良いなら接続情報を教えてほしいです」とB部署に聞く
  • B部署の担当者が「A部署の誰に権限付与すればいいですかねー？」と返答する
  • 中央アカウントの管理者が「確認しますねー(直接やり取りしてくれないかなー)」と伝える…

みたいな、エージェント時代にあるまじき不毛な人間同士のやり取りが行われるのではないかなと。本当にやりたくなさすぎますねｗ

ここのやり取りをエージェント同士でやってくれるならいいのですが、じゃあその他部署エージェントをどうやって発見するの？という問題が発生し、それを解消してくれるのがこのRegistryということで堂々巡りしかねないなと…

この辺の運用をどうするのが良いのか、AWS側はどういう想定なのか、みたいな情報が公開されると嬉しいですね。

ちなみにSkillの場合は実態がRegistry内にあるので、Registryから直接インポートできそうで非常にGoodです。
ただMCPサーバーやエージェントは実態が別のところにあるので、そっくりそのまま転用はできなそう…という認識です。

ということでかなり未来ある機能だとは思っているんですが、実運用でどう使っていくべきかが個人的にはあまり解像度高くなっていません！
有識者の方いたら教えてください🙏

おまけ：YouTubeのアーカイブ

2026/05/13(水)にJAWS-UG東京支部で春のAgentCoreアップデート解説まつりという勉強会を開催していました！

アーカイブはこちらからどうぞ！
image.png
https://www.youtube.com/live/N_YBZi8nUB8

私の登壇資料はこれです(登壇時から一部修正しています)

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?