翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ゲートウェイのインバウンド認可を設定する

ゲートウェイを作成する前に、インバウンド認可を設定する必要があります。インバウンド認可は、AgentCore ゲートウェイを介してターゲットにアクセスしようとするユーザーを検証します。AgentCore は、次のタイプのインバウンド認可をサポートしています。

Amazon Cognito を使用してデフォルトの認可設定を使用する予定がない場合は、設定方法を学ぶために使用する予定の認可のタイプに対応するトピックを選択します。

IAM ベースのインバウンド認可

IAM ベースのインバウンド認可では、ゲートウェイ発信者の IAM 認証情報を認可に使用できます。このオプションは、ゲートウェイを呼び出すユーザーが認証できる IAM ID を作成する場合に使用できます。

IAM ベースのインバウンド認可を設定するには

ポリシーの例

次の例は、ID にアタッチして、ID を使用してゲートウェイを呼び出せるようにできるポリシーを示しています。 my-gateway-12345

{
"Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowGatewayInvocation",
      "Effect": "Allow",
      "Action": [
        "bedrock-agentcore:InvokeGateway"
      ],
      "Resource": [
        "arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/my-gateway-12345"
      ]
    }
  ]
}

リソース

JSON ウェブトークン (JWT) ベースのインバウンド認可

JSON ウェブトークン (JWT) は、認可に使用される安全でコンパクトなトークンです。サポートされている ID プロバイダーを使用して JWT を作成できます。JWT を作成したら、JWT を取得し、ゲートウェイの作成時に認可設定として指定できます。

AgentCore CLI を使用して、既存の JWT ID プロバイダーでゲートウェイを設定できます。JWT 設定方法の詳細については、次のトピックから選択します。

JWT オーソライザーを設定する

サポートされている ID プロバイダーを使用してアプリケーションとクライアントを作成します。Amazon Cognito の例については、Amazon Cognito の開始方法」を参照してください。OIDC 検出 URL とクライアント ID を書き留めます。

AgentCore プロジェクトディレクトリで次のコマンドを実行します。

agentcore add gateway \
  --name MyGateway \
  --protocol-type MCP \
  --authorizer-type CUSTOM_JWT \
  --discovery-url <OIDC_DISCOVERY_URL> \
  --allowed-clients <CLIENT_ID>

AgentCore CLI は既存の OIDC 設定を使用します。ID プロバイダーリソースは作成されません。ゲートウェイを呼び出すには、プロバイダーからアクセストークンを取得します。Amazon Cognito については、Amazon Cognito デベロッパーガイド」の「トークン発行者のエンドポイント」を参照してください。

JWT を手動でセットアップする

Amazon Bedrock AgentCore は、すべての ID プロバイダーの JWTs をサポートしています。いくつかの例は、プロバイダーのセットアップと設定で確認できます。

JWT を作成するプロセスでは、次の値を書き留めます。この値は、ゲートウェイを作成するときに、ユースケースに適用できる場合に CustomJWTAuthorizerConfiguration に入力します。

以下を実行するには、これらの値が必要です。

認証チャレンジにおけるスコープアドバタイズ

クライアントが有効なアクセストークンなしで JWT 認可ゲートウェイにリクエストを送信すると、ゲートウェイは必要な OAuth スコープをアドバタイズするWWW-Authenticateヘッダーを含むエラーレスポンスを返します。これは RFC 6750 ベアラートークンチャレンジ形式に従い、MCP 準拠のクライアントがトークンの取得に必要なスコープを自動的に検出できるようにします。

ゲートウェイは、エラーに応じて次のレスポンスを返します。

scope 値には、ゲートウェイの CustomJWTAuthorizerConfiguration で許可されたスコープとして設定されたスペース区切りのスコープが含まれます。resource_metadata 値は、ゲートウェイの OAuth 保護されたリソースメタデータドキュメントを で指し/.well-known/oauth-protected-resource、クライアントが取得して認可サーバーとサポートされているスコープを検出できます。

プライベート (VPC がホストする) ID プロバイダーを使用する

AgentCore Gateway は、VPC 内でホストされている ID プロバイダーによる JWT ベースのインバウンド認可をサポートしています。AgentCore customJWTAuthorizerがパブリックインターネットに公開されることなくプライベート OIDC 検出、トークン、JWKS エンドポイントに到達できるように、 privateEndpointで を設定できます。

AgentCore Identity がAWSServiceRoleForBedrockAgentCoreIdentityサービスにリンクされたロールがまだ存在しない場合にユーザーに代わって作成できるようにidentity-network.bedrock-agentcore.amazonaws.com、IAM プリンシパルには のiam:CreateServiceLinkedRoleアクセス許可が必要です。

は、 のドメインprivateEndpointに適用されますdiscoveryUrl。ID プロバイダーが他のエンドポイントに異なるドメインを使用する場合 (たとえば、トークンまたは JWKS エンドポイントが検出 URL とは異なるドメインに解決される場合）、 privateEndpointOverridesを使用して、追加のドメインごとに個別のプライベートエンドポイント設定を指定します。

次の例では、マネージド Lattice を使用してプライベート ID プロバイダーを持つゲートウェイを作成します。

{
  "name": "my-private-idp-gateway",
  "protocolType": "MCP",
  "roleArn": "arn:aws:iam::123456789012:role/my-gateway-role",
  "authorizerType": "CUSTOM_JWT",
  "authorizerConfiguration": {
    "customJWTAuthorizer": {
      "allowedAudience": [
        "my-audience"
      ],
      "discoveryUrl": "https://my-idp.internal.example.com/.well-known/openid-configuration",
      "privateEndpoint": {
        "managedVpcResource": {
          "vpcIdentifier": "vpc-0abc123def456",
          "subnetIds": ["subnet-0abc123", "subnet-0def456"],
          "endpointIpAddressType": "IPV4",
          "securityGroupIds": ["sg-0abc123def"]
        }
      }
    }
  }
}

トークンまたは JWKS エンドポイントが検出 URL とは異なるドメインを使用している場合は、追加のドメインごとにprivateEndpointOverridesエントリを追加します。現在、 privateEndpointOverridesはセルフマネージド Lattice リソースでのみサポートされています。

{
  ...
  "authorizerConfiguration": {
    "customJWTAuthorizer": {
      "allowedAudience": ["my-audience"],
      "discoveryUrl": "https://my-idp.internal.example.com/.well-known/openid-configuration",
      "privateEndpoint": {
        "selfManagedLatticeResource": {
          "resourceConfigurationIdentifier": "arn:aws:vpc-lattice:us-east-1:123456789012:resourceconfiguration/rcfg-abc123"
        }
      },
      "privateEndpointOverrides": [
        {
          "domain": "my-token-server.internal.example.com",
          "privateEndpoint": {
            "selfManagedLatticeResource": {
              "resourceConfigurationIdentifier": "arn:aws:vpc-lattice:us-east-1:123456789012:resourceconfiguration/rcfg-def456"
            }
          }
        }
      ]
    }
  }
}

セルフマネージド Lattice、クロスアカウント設定、高度な設定については、「VPC Lattice を使用して VPC のプライベートリソースに接続する」を参照してください。インバウンドプライベート IdP シナリオとアウトバウンドプライベート IdP シナリオの両方をカバーする包括的なガイドについては、「プライベート ID プロバイダーに接続する」を参照してください。

オフロードされたインバウンド認可

オフロードされたインバウンド認可では、ゲートウェイは独自の認可決定を行いません。代わりに、認可を別のコンポーネントにオフロードします。

AgentCore には 2 つのオフロードタイプがあります。

どちらのタイプでも、認可が実際に適用される場所を決定します。

認証のみの認可

認証専用認可 (AUTHENTICATE_ONLY) では、ゲートウェイは発信者の署名バージョン 4 (SigV4) 署名を検証して ID を確認しますが、独自の認可決定は行いません。認証された IAM プリンシパルは、アクセス許可に関係なくゲートウェイを呼び出すことができ、リクエストはターゲットに転送されます。認可は、ダウンストリームのターゲットサービスまたはゲートウェイにアタッチされたポリシーエンジンに委任されます。

認可なし

を使用して、認可なしで設定されたゲートウェイを作成できますauthorizerType=NONE。ゲートウェイは受信ゲートウェイリクエストに対して認可を実行せず、リクエストは認証されていない可能性があります。

セキュリティのベストプラクティス

認証を変更せずに既存のランタイムをオンボードする

オフロードされたインバウンドタイプを、発信者の ID をランタイムに転送する一致するアウトバウンド認可タイプとペアリングする場合、ゲートウェイへのオンボーディングは、既存のクライアントでエンドポイントオーバーライドを設定するのと同じくらい簡単です。認証の変更は必要ありません。