View a markdown version of this page

透過閘道存取 AgentCore 記憶體 - Amazon Bedrock AgentCore
AgentCore 記憶體連接器請求如何流經閘道傳入和傳出身分驗證模式傳出登入資料模式如何影響記憶體存取控制

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

透過閘道存取 AgentCore 記憶體

根據預設，應用程式會直接呼叫 Amazon Bedrock AgentCore 記憶體資料平面，每個請求都會使用 AWS Signature 第 4 版 (SigV4) 進行身分驗證。您可以使用 IAM 身分型和資源型政策來控制此存取。當您的後端服務代表所有使用者呼叫記憶體，且不需要在記憶體層強制執行每個使用者的隔離時，這就很有效。

當您的後端為許多使用者呼叫記憶體時，記憶體只會看到後端的 IAM 角色。它無法驗證請求的目標最終使用者。您的應用程式程式碼必須在每個請求上設定正確的 actorId和 命名空間，以隔離一個使用者的資料與另一個使用者的資料。

透過 AgentCore 記憶體前面的 AgentCore Gateway，您可以將該強制執行從應用程式程式碼移出並移入基礎設施。 AgentCore 閘道會成為記憶體流量的單一安全進入點。它會驗證每個發起人、評估存取控制政策，並將允許的請求轉送至記憶體。使用閘道的前端記憶體提供兩種直接存取功能：

最終使用者的 OAuth 身分驗證

記憶體的資料平面僅限 SigV4-only。透過為 OAuth (JWT) 傳入身分驗證設定的閘道，您的最終使用者可以使用標準 OpenID Connect 提供者進行身分驗證，而且您的應用程式不會將 AWS 登入資料分發給他們。如需詳細資訊，請參閱使用 OAuth 將最終使用者驗證為記憶體。

精細定義存取控制

閘道可以評估將發起人限制為自己的演員、自己的命名空間或一組特定記憶體操作的政策，包括使用 OAuth 驗證的發起人。如需詳細資訊，請參閱記憶體的精細存取控制。

注意

記憶體批次操作 (BatchCreateMemoryRecords、 BatchUpdateMemoryRecords和 BatchDeleteMemoryRecords) 不支援精細存取控制。每個操作都會在單一請求中攜帶多個記錄，政策引擎無法個別評估。

這兩個功能都建置在此頁面所述的 AgentCore 記憶體連接器上。設定連接器是任一連接器的先決條件。

主題

AgentCore 記憶體連接器

AgentCore 記憶體連接器 (agentcore-memory) 是受管閘道連接器，可將閘道目標路由至 AgentCore 記憶體資料平面。連接器是一種內建目標類型：您可以建立連接器類型的目標，並僅提供連接器 ID 和目標參數，而不是自行撰寫 API 結構描述和管理端點佈線。

當您建立記憶體連接器目標時，您會提供：

  • 連接器 ID (agentcore-memory)，以及

  • 目標參數，特別是目標前端記憶體資源memoryId的 。

連接器接著會：

解決記憶體端點的問題

它會決定目標記憶體資源的正確記憶體資料平面端點。

讓支援的記憶體操作可作為 Cedar 動作使用

連接器會以 Cedar 動作的形式提供下列記憶體資料平面操作，每個操作都有其接受的請求欄位：ListEvents、CreateEvent、GetEvent、DeleteEvent、ListSessions、ListActorsRetrieveMemoryRecords、ListMemoryRecords、GetMemoryRecord、DeleteMemoryRecord、 ListMemoryExtractionJobs和 StartMemoryExtractionJob。這可讓精細存取控制政策允許或拒絕其請求屬性的特定記憶體操作和條件。如需動作 ID 和請求屬性，請參閱記憶體的精細存取控制。

注意

記憶體批次操作 (BatchCreateMemoryRecords、 BatchUpdateMemoryRecords和 BatchDeleteMemoryRecords) 不支援精細存取控制。每個操作都會在單一請求中攜帶多個記錄，政策引擎無法個別評估。

轉送請求

它會使用目標設定的傳出登入資料模式，將每個允許的請求轉送至記憶體資料平面。

由於連接器提供開箱即用的記憶體模型，因此您不會手動撰寫結構描述或管理端點配線。

請求如何流經閘道

當用戶端透過閘道呼叫記憶體時，閘道會以四個步驟處理請求：

  1. 傳入身分驗證 — 閘道會根據傳入授權方類型驗證發起人：OAuth (JWT) 承載字符、 AWS SigV4 或未經驗證的請求。請參閱傳入和傳出身分驗證模式。

  2. 動作解析 — 閘道會將傳入的 HTTP 請求 （方法和路徑） 映射到發起人正在嘗試的記憶體操作的 Cedar 動作。路徑參數和請求內文欄位會擷取到請求內容物件中。

  3. 政策評估 — 如果閘道已連接政策引擎，它會針對請求評估設定的存取控制政策。評估預設為deny-by-default。請參閱記憶體的精細存取控制。

  4. 傳出身分驗證 — 如果允許請求，閘道會使用目標的傳出憑證模式將其轉送至記憶體資料平面。請參閱傳出登入資料模式。

傳入和傳出身分驗證模式

閘道有傳入授權方類型，可控制其驗證呼叫者的方式，而每個記憶體連接器目標都有傳出登入資料模式，可控制閘道用來呼叫記憶體的身分。大多數部署使用兩種組合之一：

OAuth 最終使用者 （主要精細存取控制路徑）

CUSTOM_JWT 傳入與GATEWAY_IAM_ROLE傳出。您的使用者或客服人員向 OpenID Connect 提供者進行身分驗證，而閘道會以自己的閘道執行角色呼叫記憶體。對於非 IAM 主體的呼叫者，這是您希望每個使用者隔離時使用的組合。如需詳細資訊，請參閱使用 OAuth 將最終使用者驗證為記憶體。

具有身分傳遞的 IAM 後端服務

AWS_IAM 傳入與CALLER_IAM_CREDENTIALS傳出。閘道會將每個發起人的 IAM 身分轉送到記憶體，因此記憶體會評估發起人的 IAM 許可，而且您可以來源接腳閘道轉送的流量。當您的發起人已經是 IAM 主體，而且您希望記憶體直接授權他們時，請使用此選項。

其他組合 - 例如NONE傳GATEWAY_IAM_ROLE出AWS_IAM或傳入 - 支援特殊案例，例如 IAM 呼叫者的集中式 Cedar 強制執行或開發和測試。如需完整集，請參閱相容性矩陣。

傳入授權方類型

您可以在建立閘道時選擇傳入授權方。記憶體連接器支援 AgentCore Gateway 支援的所有傳入授權方類型。如需詳細資訊，請參閱 Amazon Bedrock AgentCore Gateway 的核心概念。

  • CUSTOM_JWT (OAuth/JWT) — 精細存取控制的主要路徑。讓發起人的 JWT 宣告可供存取控制政策使用，並為最終使用者啟用 OAuth 身分驗證。請參閱使用 OAuth 將最終使用者驗證為記憶體。

  • AWS_IAM (SigV4) — 讓發起人的 IAM 身分可供存取控制政策使用。將其用於 IAM 驗證的後端呼叫者、集中式 Cedar 強制執行或來源鎖定。

  • AUTHENTICATE_ONLY — 需要有效的簽署請求，但不會公開身分型政策規則的類型來電者身分。

  • NONE — 無授權。僅用於開發和測試；請勿將其用於生產記憶體存取。

傳出登入資料模式

傳出登入資料模式會決定記憶體資料平面看到的身分。規則很簡單：

  • 如果您的傳入身分驗證是 CUSTOM_JWT或 NONE，閘道一律使用 GATEWAY_IAM_ROLE - 它會在其閘道執行角色下呼叫記憶體。沒有其他有效的選項，也不需要選擇。

  • 如果您的傳入身分驗證是 AWS_IAM或 AUTHENTICATE_ONLY，您也可以選擇將發起人自己的 IAM 身分CALLER_IAM_CREDENTIALS轉送至記憶體，而不是使用閘道執行角色。

傳出模式 閘道如何呼叫記憶體

GATEWAY_IAM_ROLE

閘道在其閘道執行角色下呼叫記憶體 （第一方呼叫）。適用於每種傳入類型。

CALLER_IAM_CREDENTIALS

閘道會將發起人的 IAM 身分轉送至記憶體 （委派存取）。需要AWS_IAM或AUTHENTICATE_ONLY傳入，因為它需要呼叫者 IAM 身分才能轉送。

相容性矩陣

下表列出記憶體連接器目標上每個支援的傳入授權方和傳出登入資料模式組合。

傳入 GATEWAY_IAM_ROLE CALLER_IAM_CREDENTIALS

CUSTOM_JWT

支援

建立目標時拒絕

AWS_IAM

支援

支援

NONE

支援

建立目標時拒絕

AUTHENTICATE_ONLY

支援

支援

傳出登入資料模式如何影響記憶體存取控制

傳出登入資料模式會決定記憶體授權的身分，因此範圍限定於呼叫者的 IAM 政策在每個模式中的行為會有所不同。它也會決定如何使用記憶體資源型政策來限制閘道轉送的流量。

GATEWAY_IAM_ROLE

閘道在其閘道執行角色下呼叫記憶體，因此記憶體授權請求做為該角色。若要限制對此閘道的存取，您可以針對閘道執行角色 ARN 使用 aws:PrincipalArn條件，並將該角色的身分政策範圍限定為閘道所需的記憶體動作。閘道轉送的請求也會將aws:SourceArn條件金鑰集帶到閘道 ARN （請參閱下列模式）。

CALLER_IAM_CREDENTIALS

閘道會將發起人的 IAM 身分轉送至記憶體，因此記憶體會將請求授權為發起人。由於委託人是發起人而非閘道，請使用 aws:SourceArn條件來限制對閘道轉送流量的存取。

在這兩種傳出模式中，閘道會使用轉送請求的閘道 ARN 來標記aws:SourceArn條件金鑰。因此，記憶體資源型政策可以透過aws:SourceArn比對閘道 ARN 來限制對特定閘道的存取，無論傳出憑證模式為何。

重要

由於傳出登入資料模式會變更記憶體授權的身分，因此 IAM 政策範圍適用於發起人的行為會有所不同：

  • 使用 CALLER_IAM_CREDENTIALS時，記憶體會看到發起人自己的 IAM 身分。參考發起人的 IAM 身分型和資源型政策 - 包括特定 Deny上的 actorId，或 bedrock-agentcore:namespace和 等記憶體條件金鑰 bedrock-agentcore:namespacePath- 會根據該發起人進行評估。

  • 使用 GATEWAY_IAM_ROLE時，記憶體只會看到閘道執行角色。每個發起人的請求都會到達該單一角色下的記憶體，因此 IAM 政策範圍限定於個別發起人的身分 （例如特定 Deny上的 actorId)，不會針對原始發起人進行評估，也不會生效。請勿倚賴來電者範圍的 IAM 政策，在此模式下強制執行每個來電者的存取。

如果您使用 GATEWAY_IAM_ROLE且需要每個呼叫者存取控制 （例如，將呼叫者限制為自己的actorId或命名空間），請在閘道上使用精細存取控制 (Cedar 政策） 來強制執行它，而不是使用呼叫者範圍的 IAM 政策。這是主要的精細存取控制路徑。如需詳細資訊，請參閱記憶體的精細存取控制。

如需資源型政策條件金鑰和 JSON 政策範例，請參閱 Amazon Bedrock AgentCore 的資源型政策。