Il connettore AgentCore di memoria Come fluisce una richiesta attraverso il gateway Modalità di autenticazione in entrata e in uscita In che modo la modalità delle credenziali in uscita influisce sul controllo dell'accesso alla memoria

Accedi alla AgentCore memoria tramite un gateway

Per impostazione predefinita, un'applicazione richiama direttamente il piano dati di Amazon Bedrock AgentCore Memory e ogni richiesta viene autenticata con AWS Signature Version 4 (Sigv4). Puoi controllare questo accesso con policy IAM basate sull'identità e sulle risorse. Funziona bene quando il servizio di backend chiama Memory per conto di tutti gli utenti e non è necessario imporre l'isolamento per utente a livello di memoria.

Quando il backend chiama Memory per molti utenti, Memory vede solo il ruolo IAM del backend. Non è in grado di verificare a quale utente finale si rivolge una richiesta. Il codice dell'applicazione deve impostare lo spazio dei nomi corretto actorId su ogni richiesta per isolare i dati di un utente da quelli di un altro.

Con un AgentCore gateway davanti alla AgentCore memoria, puoi trasferire tale applicazione dal codice dell'applicazione all'infrastruttura. Il gateway diventa un punto di ingresso unico e sicuro per il traffico di memoria. Autentica ogni chiamante, valuta le politiche di controllo degli accessi e inoltra le richieste consentite alla memoria. Fronting Memory with a gateway offre due funzionalità che l'accesso diretto non offre:

Autenticazione OAuth per utenti finali: Il piano dati della memoria è. SigV4-only Con un gateway configurato per l'autenticazione in entrata OAuth (JWT), gli utenti finali possono autenticarsi con un provider OpenID Connect standard e l'applicazione non distribuisce loro le credenziali. AWS Per ulteriori informazioni, consulta Autenticazione degli utenti finali in memoria con OAuth.
Fine-grained controllo degli accessi: Un gateway può valutare politiche che limitano i chiamanti al proprio attore, al proprio namespace o a un set specifico di operazioni di memoria, anche per i chiamanti autenticati con OAuth. Per ulteriori informazioni, vedere Controllo degli accessi per la memoria. Fine-grained

Nota
Fine-grained il controllo degli accessi non è supportato per le operazioni batch di memoria (BatchCreateMemoryRecordsBatchUpdateMemoryRecords, eBatchDeleteMemoryRecords). Ognuna di queste operazioni contiene più record in un'unica richiesta, che il policy engine non può valutare singolarmente.

Entrambe le funzionalità sono basate sul connettore di AgentCore memoria descritto in questa pagina. La configurazione del connettore è un prerequisito per entrambe.

Argomenti

Il connettore AgentCore di memoria

Il connettore di AgentCore memoria (agentcore-memory) è un connettore gateway gestito che collega una destinazione gateway al piano dati della AgentCore memoria. I connettori sono un tipo di destinazione integrato: anziché creare uno schema API e gestire autonomamente il cablaggio degli endpoint, è possibile creare una destinazione del tipo di connettore e fornire solo l'ID del connettore e i parametri di destinazione.

Quando si crea una destinazione del connettore di memoria, si fornisce:

l'id del connettore (agentcore-memory) e
i parametri di destinazione, in particolare quelli della risorsa memoryId di memoria che fronteggia la destinazione.

Il connettore quindi:

Risolve l'endpoint di memoria: Determina l'endpoint del piano dati di memoria corretto per la risorsa di memoria della destinazione.
Rende disponibili le operazioni di memoria supportate come azioni Cedar: Il connettore rende disponibili le seguenti operazioni del piano dati di memoria come azioni Cedar, ognuna con i campi di richiesta che accetta:ListEvents,,CreateEvent,GetEvent,DeleteEvent,ListSessions,ListActors,, RetrieveMemoryRecords ListMemoryRecordsGetMemoryRecord, DeleteMemoryRecord e. ListMemoryExtractionJobs StartMemoryExtractionJob Questo è ciò che consente a politiche di controllo degli accessi granulari di consentire o negare specifiche operazioni e condizioni di memoria sugli attributi di richiesta. Per gli ID delle azioni e gli attributi delle richieste, vedere Controllo degli accessi per la memoria. Fine-grained

Nota
Le operazioni batch di memoria (BatchCreateMemoryRecordsBatchUpdateMemoryRecords, eBatchDeleteMemoryRecords) non sono supportate per il controllo granulare degli accessi. Ognuna di queste operazioni contiene più record in un'unica richiesta, che il policy engine non può valutare singolarmente.
Inoltra le richieste: Inoltra ogni richiesta consentita al piano dati di memoria utilizzando la modalità di credenziali in uscita configurata della destinazione.

Poiché il connettore fornisce il modello di memoria pronto all'uso, non è possibile creare manualmente uno schema o gestire il cablaggio degli endpoint.

Come fluisce una richiesta attraverso il gateway

Quando un client chiama Memory tramite il gateway, il gateway elabora la richiesta in quattro fasi:

Autenticazione in entrata: il gateway convalida il chiamante in base al tipo di autorizzazione in entrata: un token portante OAuth (JWT), SIGv4 o una richiesta non autenticata. AWS Vedi Modalità di autenticazione in entrata e in uscita.
Risoluzione dell'azione: il gateway associa la richiesta HTTP in entrata (metodo e percorso) all'azione Cedar per l'operazione di memoria che il chiamante sta tentando. I parametri del percorso e i campi del corpo della richiesta vengono estratti in un oggetto di contesto della richiesta.
Valutazione delle politiche: se il gateway ha un motore di policy collegato, valuta le politiche di controllo degli accessi configurate rispetto alla richiesta. La valutazione è negata per impostazione predefinita. Vedere Controllo degli Fine-grained accessi per Memory.
Autenticazione in uscita: se la richiesta è consentita, il gateway la inoltra al piano dati di memoria utilizzando la modalità credenziali in uscita della destinazione. Vedi Modalità credenziali in uscita.

Modalità di autenticazione in entrata e in uscita

Un gateway ha un tipo di autorizzazione in entrata che controlla il modo in cui autentica i chiamanti e ogni destinazione del connettore di memoria ha una modalità di credenziali in uscita che controlla l'identità utilizzata dal gateway per chiamare Memory. La maggior parte delle implementazioni utilizza una delle due combinazioni seguenti:

Utenti finali OAuth (il principale percorso di controllo degli accessi granulare): CUSTOM_JWTin entrata con uscita. GATEWAY_IAM_ROLE Gli utenti o gli agenti si autenticano con un provider OpenID Connect e il gateway chiama Memory con il proprio ruolo di esecuzione del gateway. Questa è la combinazione da utilizzare quando si desidera l'isolamento per utente per i chiamanti che non sono responsabili IAM. Per ulteriori informazioni, consulta Autenticazione degli utenti finali in memoria con OAuth.
Servizi di backend IAM con pass-through di identità: AWS_IAMin entrata con uscita. CALLER_IAM_CREDENTIALS Il gateway inoltra l'identità IAM di ogni chiamante alla memoria, in modo che Memory valuti le autorizzazioni IAM del chiamante e tu possa inserire il traffico inoltrato dal gateway come sorgente. Usalo quando i chiamanti sono già titolari IAM e desideri che Memory li autorizzi direttamente.

Altre combinazioni, ad esempio in NONE entrata e in GATEWAY_IAM_ROLE uscita, sono supportate per scenari specializzati come l'applicazione centralizzata di Cedar per i chiamanti IAM AWS_IAM o lo sviluppo e il test. Consulta la matrice di compatibilità per il set completo.

Tipi di autorizzatori in entrata

Scegli l'autorizzatore in entrata quando crei il gateway. Il connettore di memoria supporta tutti i tipi di autorizzazione in entrata supportati da Gateway. AgentCore Per ulteriori informazioni, consulta Concetti fondamentali per Amazon AgentCore Bedrock Gateway.

CUSTOM_JWT(OAuth/JWT) — il percorso principale per il controllo granulare degli accessi. Rende le dichiarazioni JWT del chiamante disponibili per le politiche di controllo degli accessi e abilita l'autenticazione OAuth per gli utenti finali. Vedi Autenticazione degli utenti finali in memoria con OAuth.
AWS_IAM(SIGv4): rende l'identità IAM del chiamante disponibile per le politiche di controllo degli accessi. Usalo per i chiamanti IAM-authenticated backend, per l'applicazione centralizzata di Cedar o per il source-pinning.
AUTHENTICATE_ONLY— richiede una richiesta firmata valida ma non espone l'identità digitata del chiamante per le regole di policy basate sull'identità.
NONE— nessuna autorizzazione. Destinato esclusivamente allo sviluppo e al test; non utilizzarlo per l'accesso alla memoria di produzione.

Modalità credenziali in uscita

La modalità credenziali in uscita determina l'identità visualizzata dal piano dati di memoria. La regola è semplice:

Se l'autenticazione in ingresso è CUSTOM_JWT oNONE, il gateway utilizza sempreGATEWAY_IAM_ROLE: chiama Memory sotto il suo ruolo di esecuzione del gateway. Non ci sono altre opzioni valide e non c'è nulla da scegliere.
Se l'autenticazione in entrata è AWS_IAM oAUTHENTICATE_ONLY, puoi inoltre scegliere di CALLER_IAM_CREDENTIALS inoltrare l'identità IAM del chiamante alla memoria, invece di utilizzare il ruolo di esecuzione del gateway.

Modalità in uscita	Come il gateway chiama Memory
`GATEWAY_IAM_ROLE`	Il gateway chiama Memory nell'ambito del suo ruolo di esecuzione del gateway (una chiamata proprietaria). Funziona con ogni tipo di ingresso.
`CALLER_IAM_CREDENTIALS`	Il gateway inoltra l'identità IAM del chiamante alla memoria (accesso delegato). Richiede `AWS_IAM` o è `AUTHENTICATE_ONLY` in entrata, perché necessita di un'identità IAM del chiamante per l'inoltro.

Matrice di compatibilità

La tabella seguente elenca tutte le combinazioni supportate di modalità di autorizzazione in entrata e credenziali in uscita sulla destinazione del connettore di memoria.

In entrata	`GATEWAY_IAM_ROLE`	`CALLER_IAM_CREDENTIALS`
`CUSTOM_JWT`	Supportata	Rifiutato al momento della creazione dell'
`AWS_IAM`	Supportata	Supportato
`NONE`	Supportata	Rifiutato alla creazione dell'obiettivo
`AUTHENTICATE_ONLY`	Supportata	Supportata

In che modo la modalità delle credenziali in uscita influisce sul controllo dell'accesso alla memoria

La modalità delle credenziali in uscita determina l'identità autorizzata dalla memoria, pertanto le policy IAM destinate al chiamante si comportano diversamente in ciascuna modalità. Determina inoltre come limitare il traffico inoltrato dal gateway con una policy basata sulle risorse di memoria. Resource-based politiche per Amazon Bedrock AgentCore

GATEWAY_IAM_ROLE: Il gateway chiama Memory nell'ambito del suo ruolo di esecuzione del gateway, pertanto Memory autorizza la richiesta con quel ruolo. Per limitare l'accesso a questo gateway, è possibile utilizzare la aws:PrincipalArn condizione rispetto al ruolo di esecuzione del gateway ARN e limitare la politica di identità di quel ruolo alle sole azioni di memoria necessarie al gateway. Le richieste inoltrate dal gateway contengono anche la chiave di aws:SourceArn condizione impostata sull'ARN del gateway (vedere la modalità seguente).
CALLER_IAM_CREDENTIALS: Il gateway inoltra l'identità IAM del chiamante alla memoria, quindi Memory autorizza la richiesta come chiamante. Poiché il principale è il chiamante e non il gateway, utilizza aws:SourceArn questa condizione per limitare l'accesso al traffico inoltrato dal gateway.

In entrambe le modalità in uscita, il gateway contrassegna sulla chiave di aws:SourceArn condizione l'ARN del gateway che ha inoltrato la richiesta. Una policy basata sulle risorse di memoria può quindi limitare l'accesso a un gateway specifico confrontandolo con l'ARN del gateway, indipendentemente dalla modalità delle aws:SourceArn credenziali in uscita.

Importante

Poiché la modalità delle credenziali in uscita modifica l'identità autorizzata da Memory, le policy IAM destinate al chiamante si comportano diversamente:

ConCALLER_IAM_CREDENTIALS, Memory vede l'identità IAM propria del chiamante. Le policy IAM basate sull'identità e sulle risorse che fanno riferimento al chiamante, tra cui a Deny su uno specificoactorId, o le chiavi di condizione della memoria come bedrock-agentcore:namespace e, vengono valutate rispetto a quel chiamante. bedrock-agentcore:namespacePath
ConGATEWAY_IAM_ROLE, Memory vede solo il ruolo di esecuzione del gateway. Ogni richiesta del chiamante raggiunge la Memoria con quel singolo ruolo, quindi le policy IAM basate sull'identità di un singolo chiamante (ad esempio Deny su uno specificoactorId) non vengono valutate rispetto al chiamante originale e non hanno effetto. Non affidatevi a policy IAM basate sull'ambito del chiamante per imporre l'accesso per chiamante in questa modalità.

Se utilizzi GATEWAY_IAM_ROLE e hai bisogno del controllo degli accessi per chiamante (ad esempio, limitando un chiamante al proprio spazio dei nomi), applicalo con un controllo di accesso actorId granulare (policy Cedar) sul gateway anziché con politiche IAM con ambito chiamante. Questo è il principale percorso granulare di controllo degli accessi. Per ulteriori informazioni, vedere Controllo degli Fine-grained accessi per la memoria.

Per le chiavi di condizione delle policy basate sulle risorse e gli esempi di policy JSON, consulta Resource-based le policy per Amazon Bedrock. AgentCore

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Argomenti avanzati

Configura il connettore