Configurer les autorisations pour AgentCore Gateway
Pour utiliser Amazon Bedrock AgentCore Gateway et ses fonctionnalités, vous devez prendre en compte les autorisations suivantes :
-
Autorisations de passerelle : builder/user autorisations accordées à un créateur de passerelle ou à un utilisateur pour lui permettre de créer, de gérer et/ou d'utiliser des AgentCore passerelles.
-
Autorisations de rôle de service de passerelle : autorisations accordées à un rôle de service que vous allez créer pour votre passerelle. Ces autorisations permettent au AgentCore service Amazon Bedrock d'effectuer des actions au nom de l'identité qui invoque la passerelle.
-
Resource-based autorisations : autorisations associées aux ressources pour permettre au rôle de service de passerelle d'y accéder. Vous allez inclure le nom de ressource Amazon (ARN) du rôle de service de passerelle
Principaldans la politique basée sur les ressources. -
Politiques basées sur les ressources de la passerelle : politiques directement associées aux ressources de votre passerelle pour contrôler les principaux autorisés à les invoquer. Pour plus d'informations, consultez les Resource-based politiques d'Amazon Bedrock AgentCore.
Note
Si vous préférez ne pas configurer d'autorisations personnalisées, vous pouvez utiliser les options suivantes pour faciliter la configuration :* Associer le BedrockAgentCoreFullAccessà une identité IAM pour lui permettre de créer, de gérer et d'appeler des passerelles. * Utilisez la console AWS de gestion ou la AgentCore CLI pour créer un rôle de service de AgentCore passerelle doté des autorisations appropriées et des cibles de passerelle dotées des politiques basées sur les ressources appropriées pour permettre au rôle de service d'y accéder.
Choisissez une rubrique pour en savoir plus :
Rubriques
Générateur de passerelle et autorisations utilisateur
Pour qu'une identité puisse créer, gérer ou utiliser des passerelles, vous devez associer une politique basée sur l'identité à l'identité IAM afin de lui permettre d'effectuer des actions Amazon Bedrock. AgentCore-related Pour obtenir des autorisations complètes, vous pouvez utiliser la politique BedrockAgentCoreFullAccessgérée.
Pour une sécurité et un contrôle accrus, vous pouvez créer votre propre politique personnalisée en réduisant les autorisations dans la politique d'accès complet. Par exemple, la politique suivante permet à une identité d'effectuer des actions liées à AgentCore Gateway, mais pas à d'autres AgentCore services, tels que AgentCore Runtime ou AgentCore Browser :
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "bedrock-agentcore:*Gateway*", "bedrock-agentcore:*WorkloadIdentity", "bedrock-agentcore:*CredentialProvider", "bedrock-agentcore:*Token*", "bedrock-agentcore:*Access*" ], "Resource": "arn:aws:bedrock-agentcore:*:*:*gateway*" } ] }
- La politique personnalisée suivante est plus restrictive et autorise uniquement l'accès en lecture aux passerelles et aux cibles des passerelles.
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "bedrock-agentcore:ListGateways", "bedrock-agentcore:GetGateway", "bedrock-agentcore:ListGatewayTargets", "bedrock-agentcore:GetGatewayTarget" ], "Resource": "arn:aws:bedrock-agentcore:*:*:*gateway*" } ] }
Autorisations d'accès à la passerelle (autorisation entrante)
Outre les autorisations liées à la passerelle, vous devez également configurer des autorisations pour les identités afin de pouvoir accéder à la passerelle lors de l'invocation. Vous allez configurer ces autorisations lorsque vous configurez l'autorisation entrante.
AgentCore Autorisations de rôle du service de passerelle
Lorsque vous créez une passerelle, vous avez besoin d'un rôle de service autorisé à assumer un rôle IAM et à accéder aux AWS ressources et aux services externes au nom du rôle IAM. Vous pouvez créer le rôle de service de différentes manières :
-
Si vous créez une passerelle dans la console AWS de gestion ou via la AgentCore CLI, vous pouvez choisir de laisser créer AgentCore automatiquement un rôle de service pour vous avec les autorisations nécessaires. Si vous préférez cette méthode, vous pouvez ignorer cette condition préalable.
-
Si vous préférez créer votre propre rôle de service pour une plus grande personnalisation, vous devez le configurer avec les autorisations décrites dans cette rubrique. Pour savoir comment créer un rôle de service et y associer des autorisations, voir Créer un rôle pour déléguer des autorisations à un AWS service.
Les autorisations requises pour un rôle de service sont décrites dans les rubriques suivantes :
Rubriques
Autorisations de confiance
Un rôle de service doit être associé à une politique de confiance qui permet au AgentCore service d'assumer une identité IAM et d'effectuer des actions en son nom.
Voici un exemple de politique de confiance que vous pouvez utiliser.
{ "Version":"2012-10-17", "Statement": [ { "Sid": "GatewayAssumeRolePolicy", "Effect": "Allow", "Principal": { "Service": "bedrock-agentcore.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333" }, "ArnLike": { "aws:SourceArn": "arn:aws:bedrock-agentcore:us-east-1:111122223333:gateway/gateway-name-*" } } } ] }
Note
Comme vous ne connaîtrez pas l'ARN de la passerelle avant de le créer, vous pouvez omettre le Condition champ lorsque vous créez le rôle de service pour la première fois. Après avoir créé la passerelle, ajoutez à nouveau le Condition champ à la politique en tant que meilleure pratique de sécurité et procédez comme suit :* Remplacez la valeur de la clé de aws:SourceAccount condition par l'ID du compte auquel appartient la passerelle. * Remplacez la clé de aws:SourceArn condition par l'ARN de la passerelle.
Autorisations d'autorisation sortantes
Selon le type d'autorisation sortante que vous utilisez pour les cibles de votre passerelle, vous devez ajouter des autorisations au rôle de service pour lui permettre d'appeler la cible. Ces autorisations permettent au rôle de service de passerelle de récupérer les informations d'identification permettant d'appeler la cible. Vous pouvez le faire lors de la configuration de l'autorisation sortante.
Autorisations d'accès AWS resources
En fonction de la configuration de votre passerelle ou des cibles que vous choisissez d'ajouter à la passerelle, vous devrez peut-être ajouter des autorisations au rôle de service de passerelle pour lui permettre d'accéder aux AWS ressources. Les rubriques suivantes couvrent certaines ressources auxquelles votre rôle de service de passerelle peut avoir besoin d'accéder :
Si vous associez une cible Lambda à votre passerelle, vous devez ajouter des autorisations pour le rôle de service de AgentCore passerelle afin de pouvoir invoquer la fonction en procédant comme suit :
-
Associez une politique basée sur l'identité au rôle de service AgentCore Gateway qui autorise l'
lambda:InvokeFunctionaction sur la ressource de la fonction Lambda. -
(Si la fonction se trouve dans un compte différent de celui du rôle de service de passerelle) Attachez une politique basée sur les ressources à la fonction Lambda qui permet au principal du rôle de service de passerelle d'effectuer l'action
lambda:InvokeFunctionsur la ressource de la fonction Lambda.
Sélectionnez une rubrique pour savoir comment configurer les autorisations :
Rubriques
===== Associer une politique basée sur l'identité au rôle de service de passerelle
Pour autoriser le rôle de service de passerelle à accéder à une cible Lambda, associez la politique d'identité suivante à votre rôle de service de AgentCore passerelle en choisissant le sujet dans Ajouter et supprimer des autorisations d'identité IAM correspondant à votre cas d'utilisation et en suivant les étapes.
{ "Version": "2012-10-17", "Statement": [{ "Sid": "AmazonBedrockAgentCoreGatewayLambdaProd", "Effect": "Allow", "Action": [ "lambda:InvokeFunction" ], "Resource": [ "arn:aws:lambda:us-east-1:123456789012:function:FunctionName" ] }] }
Remplacez l'ARN du Resource champ par l'ARN de votre passerelle de fonctions Lambda cible. Si votre passerelle possède plusieurs cibles Lambda, vous pouvez ajouter l'ARN de chaque fonction à la Resource liste.
===== (Si la fonction se trouve dans un autre compte) Attachez une politique basée sur les ressources à la fonction Lambda
Si la cible de la fonction Lambda se trouve dans un compte différent de celui du rôle de service de passerelle, vous devez associer une politique basée sur les ressources pour autoriser le rôle de service de passerelle à y accéder. Voici un exemple de politique que vous pouvez utiliser :
{ "Version":"2012-10-17", "Statement": [ { "Sid": "LambdaAllowGatewayServiceRoleMyFunction", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/MyGatewayExecutionRole" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:MyFunction" } ] }
Remplacez les valeurs des champs suivants :
-
AWS— Utilisez l'ARN de votre rôle de service de passerelle. -
Resource— Utilisez l'ARN de votre fonction Lambda.- Pour savoir comment associer une politique basée sur les ressources à la fonction Lambda afin de permettre à votre rôle de service de passerelle d'accéder à la fonction, sélectionnez l'une des méthodes suivantes
Exemple
Si vous prévoyez d'inclure une définition d'outil cible de passerelle à partir d'une URI Amazon S3, vous devez inclure les autorisations permettant au rôle de service de passerelle d'accéder au compartiment. La AmazonS3ReadOnlyAccessstratégie est un exemple de stratégie que vous pouvez associer au rôle de service. Vous pouvez vous étendre Resource jusqu'à l'emplacement S3 pour plus de sécurité.
Si vous envisagez d'ajouter une cible Smithy, vous devez ajouter des autorisations pour le rôle de service de passerelle afin d'accéder aux AWS services auxquels vos modèles Smithy font référence. Pour déterminer quelles autorisations doivent être associées au rôle de service, reportez-vous à la documentation de ce service.
Vous pouvez ajouter des autorisations au rôle de service en choisissant le sujet dans Ajouter et supprimer des autorisations d'identité IAM correspondant à votre cas d'utilisation, puis en suivant les étapes indiquées.
Par exemple, si la cible de votre modèle Smithy accède à une table DynamoDB, vous pouvez joindre la politique suivante pour autoriser le rôle de service à effectuer des opérations DynamoDB sur la table :
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:Query", "dynamodb:Scan" ], "Resource": "arn:aws:dynamodb:*:*:table/*" } ] }
Bonnes pratiques pour les autorisations de passerelle
- Respectez le principe du moindre privilège
-
-
Accordez uniquement les autorisations nécessaires au fonctionnement de votre passerelle
-
Utilisez des ARN de ressources spécifiques plutôt que des caractères génériques lorsque cela est possible
-
Vérifiez et auditez régulièrement les autorisations
-
- Séparer les rôles par fonction
-
-
Utiliser différents rôles pour la gestion et l'exécution
-
Créez des rôles distincts pour différentes passerelles ayant des objectifs différents
-
- Stockage sécurisé des informations d'identification
-
-
Stockez les clés d'API et les informations d'identification OAuth dans Secrets Manager AWS
-
Effectuer une rotation régulière des informations d'identification
-
- Surveillance et audit
-
-
Activer la CloudTrail journalisation pour les opérations de Gateway
-
Passez régulièrement en revue les modèles d'accès et l'utilisation des autorisations
-
- Conditions d'utilisation dans les politiques
-
-
Ajoutez des conditions pour limiter quand et comment les autorisations peuvent être utilisées
-
Envisagez d'utiliser des restrictions d'adresse IP source pour les opérations de gestion
-