Le connecteur AgentCore de mémoire Comment une demande passe par la passerelle Modes d'authentification entrants et sortants Comment le mode d'identification sortant affecte le contrôle d'accès à la mémoire

Accès à AgentCore la mémoire via une passerelle

Par défaut, une application appelle directement le plan de données Amazon Bedrock AgentCore Memory, et chaque demande est authentifiée avec AWS Signature Version 4 (Sigv4). Vous pouvez contrôler cet accès à l'aide de politiques IAM basées sur l'identité et sur les ressources. Cela fonctionne bien lorsque votre service principal appelle Memory pour le compte de tous les utilisateurs et n'a pas besoin d'appliquer une isolation par utilisateur au niveau de la couche mémoire.

Lorsque votre backend appelle Memory pour de nombreux utilisateurs, Memory ne voit que le rôle IAM de votre backend. Il ne peut pas vérifier à quel utilisateur final s'adresse une demande. Le code de votre application doit définir l'espace actorId de noms correct pour chaque demande afin d'isoler les données d'un utilisateur de celles d'un autre.

Avec une AgentCore passerelle située devant la AgentCore mémoire, vous pouvez transférer cette application hors du code de votre application vers l'infrastructure. La passerelle devient un point d'entrée unique et sécurisé pour le trafic mémoire. Il authentifie chaque appelant, évalue les politiques de contrôle d'accès et transmet les demandes autorisées à Memory. La mémoire frontale avec passerelle vous offre deux fonctionnalités que l'accès direct n'offre pas :

Authentification OAuth pour les utilisateurs finaux: Le plan de données de la mémoire est SigV4-only. Avec une passerelle configurée pour l'authentification entrante OAuth (JWT), vos utilisateurs finaux peuvent s'authentifier auprès d'un fournisseur OpenID Connect standard, et votre application ne leur distribue pas d'informations d'identification. AWS Pour plus d'informations, consultez Authentifier les utilisateurs finaux en mémoire avec OAuth.
Fine-grained contrôle d'accès: Une passerelle peut évaluer les politiques qui limitent les appelants à leur propre acteur, à leur propre espace de noms ou à un ensemble spécifique d'opérations de mémoire, y compris pour les appelants authentifiés avec OAuth. Pour plus d'informations, consultez la section Contrôle Fine-grained d'accès à la mémoire.

Note
Fine-grained le contrôle d'accès n'est pas pris en charge pour les opérations par lots de mémoire (BatchCreateMemoryRecordsBatchUpdateMemoryRecords, etBatchDeleteMemoryRecords). Chacune de ces opérations contient plusieurs enregistrements dans une seule demande, que le moteur de politiques ne peut pas évaluer individuellement.

Les deux fonctionnalités sont basées sur le connecteur de AgentCore mémoire décrit sur cette page. La configuration du connecteur est une condition préalable pour l'un ou l'autre.

Rubriques

Le connecteur AgentCore de mémoire

Le connecteur de AgentCore mémoire (agentcore-memory) est un connecteur de passerelle géré qui connecte une cible de passerelle au plan de données de la AgentCore mémoire. Les connecteurs sont un type de cible intégré : au lieu de créer un schéma d'API et de gérer vous-même le câblage des terminaux, vous créez une cible correspondant au type de connecteur et ne fournissez que l'identifiant du connecteur et les paramètres cibles.

Lorsque vous créez une cible Memory Connector, vous devez fournir :

l'identifiant du connecteur (agentcore-memory), et
les paramètres cibles, notamment ceux memoryId de la ressource mémoire que la cible met en avant.

Le connecteur :

Résout le point de terminaison de mémoire: Il détermine le point de terminaison du plan de données mémoire correct pour la ressource mémoire de la cible.
Rend les opérations de mémoire prises en charge disponibles sous forme d'actions Cedar: Le connecteur rend les opérations suivantes sur le plan de données de la mémoire disponibles sous forme d'actions CedarListEvents, chacune avec les champs de requête qu'elle accepte : CreateEvent GetEvent DeleteEvent ListSessionsListActors,RetrieveMemoryRecords,ListMemoryRecords,GetMemoryRecord,DeleteMemoryRecord,ListMemoryExtractionJobs, etStartMemoryExtractionJob. C'est ce qui permet à des politiques de contrôle d'accès affinées d'autoriser ou de refuser des opérations de mémoire spécifiques et de conditionner leurs attributs de demande. Pour les identifiants d'action et les attributs de demande, consultez la section Contrôle Fine-grained d'accès pour la mémoire.

Note
Les opérations par lots de mémoire (BatchCreateMemoryRecordsBatchUpdateMemoryRecords, etBatchDeleteMemoryRecords) ne sont pas prises en charge pour un contrôle d'accès précis. Chacune de ces opérations contient plusieurs enregistrements dans une seule demande, que le moteur de politiques ne peut pas évaluer individuellement.
Transfère les demandes: Il transmet chaque demande autorisée au plan de données de la mémoire en utilisant le mode d'identification sortant configuré pour la cible.

Comme le connecteur fournit le modèle de mémoire prêt à l'emploi, vous ne pouvez pas créer manuellement de schéma ni gérer le câblage des terminaux.

Comment une demande passe par la passerelle

Lorsqu'un client appelle Memory via la passerelle, celle-ci traite la demande en quatre étapes :

Authentification entrante : la passerelle valide l'appelant en fonction de son type d'autorisation entrante : un jeton porteur OAuth (JWT), Sigv4 ou une demande non authentifiée. AWS Consultez la section Modes d'authentification entrants et sortants.
Résolution des actions : la passerelle associe la requête HTTP entrante (méthode et chemin) à l'action Cedar pour l'opération de mémoire que l'appelant tente de réaliser. Les paramètres de chemin et les champs du corps de la demande sont extraits dans un objet de contexte de demande.
Évaluation des politiques : si la passerelle est associée à un moteur de politiques, elle évalue les politiques de contrôle d'accès configurées par rapport à la demande. L'évaluation est refusée par défaut. Consultez la section Contrôle Fine-grained d'accès pour la mémoire.
Authentification sortante : si la demande est autorisée, la passerelle la transmet au plan de données de la mémoire en utilisant le mode d'identification sortant de la cible. Consultez la section Mode d'identification sortant.

Modes d'authentification entrants et sortants

Une passerelle possède un type d'autorisation entrante qui contrôle la manière dont elle authentifie les appelants, et chaque cible Memory Connector possède un mode d'identification sortant qui contrôle l'identité que la passerelle utilise pour appeler Memory. La plupart des déploiements utilisent l'une des deux combinaisons suivantes :

Utilisateurs finaux OAuth (le principal chemin de contrôle d'accès précis): CUSTOM_JWTentrant et sortant. GATEWAY_IAM_ROLE Vos utilisateurs ou agents s'authentifient auprès d'un fournisseur OpenID Connect, et la passerelle appelle Memory sous son propre rôle d'exécution de passerelle. Il s'agit de la combinaison à utiliser lorsque vous souhaitez isoler par utilisateur les appelants qui ne sont pas des responsables IAM. Pour plus d'informations, consultez Authentifier les utilisateurs finaux en mémoire avec OAuth.
Services dorsaux IAM avec transfert d'identité: AWS_IAMentrant et sortant. CALLER_IAM_CREDENTIALS La passerelle transmet l'identité IAM de chaque appelant à Memory. Memory évalue donc les autorisations IAM de l'appelant et vous pouvez utiliser le code source du trafic transféré par passerelle. Utilisez-le lorsque vos appelants sont déjà des responsables IAM et que vous souhaitez que Memory les autorise directement.

D'autres combinaisons, telles que AWS_IAM l'NONEentrée et la GATEWAY_IAM_ROLE sortie, sont prises en charge pour des scénarios spécialisés tels que l'application centralisée de Cedar pour les appelants IAM ou le développement et les tests. Consultez la matrice de compatibilité pour l'ensemble complet.

Types d'autorisateurs entrants

Vous choisissez l'autorisateur entrant lorsque vous créez la passerelle. Le connecteur de mémoire prend en charge tous les types d'autorisations entrants pris en charge par AgentCore Gateway. Pour plus d'informations, consultez la section Concepts fondamentaux d'Amazon Bedrock AgentCore Gateway.

CUSTOM_JWT(OAuth/JWT) : le chemin principal pour un contrôle d'accès précis. Met les demandes JWT de l'appelant à la disposition des politiques de contrôle d'accès et active l'authentification OAuth pour les utilisateurs finaux. Consultez Authentifier les utilisateurs finaux en mémoire avec OAuth.
AWS_IAM(Sigv4) : met l'identité IAM de l'appelant à la disposition des politiques de contrôle d'accès. Utilisez-le pour les appelants IAM-authenticated principaux, l'application centralisée de Cedar ou l'épinglage à la source.
AUTHENTICATE_ONLY— nécessite une demande signée valide mais n'expose pas l'identité de l'appelant saisie pour les règles de politique basées sur l'identité.
NONE— aucune autorisation. Destiné uniquement au développement et aux tests ; ne l'utilisez pas pour accéder à la mémoire de production.

Mode d'identification sortant

Le mode d'identification sortant détermine l'identité détectée par le plan de données de la mémoire. La règle est simple :

Si votre authentification entrante est CUSTOM_JWT ouNONE, la passerelle l'utilise toujours GATEWAY_IAM_ROLE : elle appelle Memory dans le cadre de son rôle d'exécution de passerelle. Il n'y a pas d'autre option valable et il n'y a rien à choisir.
Si votre authentification entrante est AWS_IAM ouAUTHENTICATE_ONLY, vous pouvez également choisir de CALLER_IAM_CREDENTIALS transférer l'identité IAM de l'appelant vers Memory, au lieu d'utiliser le rôle d'exécution de la passerelle.

Mode sortant	Comment la passerelle appelle Memory
`GATEWAY_IAM_ROLE`	La passerelle appelle Memory dans le cadre de son rôle d'exécution de passerelle (un appel interne). Fonctionne avec tous les types de trafic entrant.
`CALLER_IAM_CREDENTIALS`	La passerelle transmet l'identité IAM de l'appelant à Memory (accès délégué). Requiert `AWS_IAM` ou `AUTHENTICATE_ONLY` entrant, car il a besoin de l'identité IAM de l'appelant pour le transférer.

Matrice de compatibilité

Le tableau suivant répertorie toutes les combinaisons prises en charge entre le mode d'autorisation entrante et le mode d'identification sortant sur la cible du connecteur de mémoire.

Entrant	`GATEWAY_IAM_ROLE`	`CALLER_IAM_CREDENTIALS`
`CUSTOM_JWT`	Pris en charge	Rejeté lors de la création de la cible
`AWS_IAM`	Pris en charge	Pris en charge
`NONE`	Pris en charge	Rejeté lors de la création de la cible
`AUTHENTICATE_ONLY`	Pris en charge	Pris en charge

Comment le mode d'identification sortant affecte le contrôle d'accès à la mémoire

Le mode d'identification sortant détermine l'identité que Memory autorise, de sorte que les politiques IAM qui concernent l'appelant se comportent différemment dans chaque mode. Il détermine également la manière dont vous pouvez restreindre le trafic transféré par passerelle à l'aide d'une politique basée sur les ressources mémoire.

GATEWAY_IAM_ROLE: La passerelle appelle Memory dans le cadre de son rôle d'exécution de passerelle, de sorte que Memory autorise la demande sous ce rôle. Pour restreindre l'accès à cette passerelle, vous pouvez appliquer la aws:PrincipalArn condition à l'ARN du rôle d'exécution de la passerelle et étendre la politique d'identité de ce rôle aux seules actions de mémoire dont la passerelle a besoin. Les demandes transmises par la passerelle transportent également la clé de aws:SourceArn condition définie dans l'ARN de la passerelle (voir le mode suivant).
CALLER_IAM_CREDENTIALS: La passerelle transmet l'identité IAM de l'appelant à Memory, afin que Memory autorise la demande en tant qu'appelant. Étant donné que le principal est l'appelant plutôt que la passerelle, utilisez la aws:SourceArn condition pour restreindre l'accès au trafic transféré par la passerelle.

Dans les deux modes sortants, la passerelle tamponne la clé de aws:SourceArn condition avec l'ARN de la passerelle qui a transmis la demande. Une politique basée sur les ressources mémoire peut donc restreindre l'accès à une passerelle spécifique en la aws:SourceArn comparant à l'ARN de la passerelle, quel que soit le mode d'identification sortant.

Important

Étant donné que le mode d'identification sortant modifie l'identité autorisée par Memory, les politiques IAM limitées à l'appelant se comportent différemment :

AvecCALLER_IAM_CREDENTIALS, Memory voit l'identité IAM de l'appelant. Les politiques IAM basées sur l'identité et les ressources qui font référence à l'appelant, y compris une clé Deny relative à un utilisateur spécifique ou des clés d'état de la mémoire telles que bedrock-agentcore:namespace et actorIdbedrock-agentcore:namespacePath, sont évaluées par rapport à cet appelant.
AvecGATEWAY_IAM_ROLE, Memory ne voit que le rôle d'exécution de la passerelle. La demande de chaque appelant atteint Memory sous ce rôle unique, de sorte que les politiques IAM limitées à l'identité d'un appelant individuel (par exemple, Deny sur un appelant spécifiqueactorId) ne sont pas évaluées par rapport à l'appelant d'origine et ne prennent pas effet. Ne vous fiez pas aux politiques IAM définies par l'appelant pour appliquer l'accès par appelant dans ce mode.

Si vous utilisez GATEWAY_IAM_ROLE et avez besoin d'un contrôle d'accès par appelant (par exemple, restreindre un appelant à son propre actorId espace de noms), appliquez-le à l'aide d'un contrôle d'accès précis (politiques Cedar) sur la passerelle plutôt qu'à l'aide de politiques IAM limitées à l'appelant. Il s'agit de la principale voie de contrôle d'accès précise. Pour plus d'informations, consultez la section Contrôle Fine-grained d'accès à la mémoire.

Pour les clés de condition de politique basées sur les ressources et des exemples de politiques JSON, consultez Resource-based les politiques d'Amazon Bedrock. AgentCore

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Rubriques avancées

Configurer le connecteur