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

ゲートウェイを作成する前に、インバウンド認可を設定する必要があります。インバウンド認可は、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 を設定する

AgentCore CLI を使用すると、Amazon Cognito を使用してデフォルトの認可設定を簡単に作成し、ゲートウェイの作成時に使用できます。を実行するとagentcore create、CLI からインバウンド認可を設定するように求められ、自動的に Amazon Cognito ユーザープールを設定できます。

agentcore create

コマンドが完了すると、AgentCore CLI は認証情報と認可情報を提供します。

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 をランタイムに転送する一致するアウトバウンド認可タイプとペアリングする場合、ゲートウェイへのオンボーディングは、既存のクライアントでエンドポイントオーバーライドを設定するのと同じくらい簡単です。認証の変更は必要ありません。