# Configurer les autorisations pour AgentCore Gateway
Pour utiliser Amazon Bedrock AgentCore Gateway et ses fonctionnalités, vous devez prendre en compte les autorisations suivantes :
1. 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.
1. 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.
1. **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 `Principal` dans la politique basée sur les ressources.
1. **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](resource-based-policies.md).
**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](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/BedrockAgentCoreFullAccess.html)à 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 :
**Topics**
+ [Générateur de passerelle et autorisations utilisateur](#gateway-user-permissions)
+ [AgentCore Autorisations de rôle du service de passerelle](#gateway-service-role-permissions)
+ [Bonnes pratiques pour les autorisations de passerelle](#gateway-prerequisites-best-practices)
## 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 ](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonbedrockagentcore.html) Pour obtenir des autorisations complètes, vous pouvez utiliser la politique [BedrockAgentCoreFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/BedrockAgentCoreFullAccess.html)gé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](gateway-inbound-auth.md).
## 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](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-service.html).
Les autorisations requises pour un rôle de service sont décrites dans les rubriques suivantes :
**Topics**
+ [Autorisations de confiance](#gateway-service-role-permissions-trust)
+ [Autorisations d'autorisation sortantes](#gateway-service-role-permissions-outbound-auth)
+ [Autorisations d'accès AWS resources](#gateway-service-role-permissions-resources)
### Autorisations de confiance
Un rôle de service doit être associé à une [politique de confiance](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#term_trust_policy) 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](gateway-outbound-auth.md).
### 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 :
#### Accéder à une fonction Lambda
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:InvokeFunction`action 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:InvokeFunction` sur la ressource de la fonction Lambda.
Sélectionnez une rubrique pour savoir comment configurer les autorisations :
**Topics**
===== 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) à 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
------
#### [ Console ]
1. ====== Pour associer une politique basée sur les ressources à votre fonction Lambda dans la console de gestion AWS
1. Suivez les étapes décrites dans l'onglet **Console** de la section [Affichage des politiques IAM basées sur les ressources dans](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html) Lambda.
1. Dans la section **des déclarations de Resource-based politique**, choisissez **Ajouter des autorisations**.
1. Sélectionnez un ** AWS compte** et renseignez les champs suivants :
+ **ID de déclaration** : identifiant unique pour l'instruction fournissant les autorisations permettant au rôle de service de passerelle d'accéder à la fonction.
+ **Principal** — Spécifiez l'ARN de votre rôle de service de passerelle.
+ **Action** — Sélectionnez`lambda:InvokeFunction`.
------
#### [ CLI ]
1. Pour associer une politique basée sur les ressources à votre fonction Lambda à l'aide de la AWS CLI, suivez les étapes décrites dans la section Accorder l'[accès aux AWS services à la fonction Lambda et spécifiez votre rôle de service](https://docs.aws.amazon.com/lambda/latest/dg/permissions-function-services.html) de passerelle en tant que. `principal`
Vous pouvez exécuter le code suivant dans un terminal pour ajouter des autorisations permettant à votre rôle de service de passerelle d'accéder à la fonction dans {{us-east-1}} :
```
aws lambda add-permission \
--function-name "MyFunction" \
--statement-id "GatewayInvoke" \
--action "lambda:InvokeFunction" \
--principal "arn:aws:iam::123456789012:role/MyGatewayServiceRole"
--region us-east-1
```
------
**Example**
#### Accédez aux objets Amazon S3
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 [AmazonS3ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3ReadOnlyAccess.html)straté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é.
#### Autorisations du modèle Smithy
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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) à 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