View a markdown version of this page

Configurer l'autorisation sortante pour votre passerelle - Base rocheuse de l'Amazonie AgentCore
Configurer l'autorisation IAM-based sortante avec un rôle de service de passerelleConfigurer l'autorisation sortante avec un client OAuthConfigurer l'autorisation sortante à l'aide d'une clé API

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Configurer l'autorisation sortante pour votre passerelle

L'autorisation sortante permet aux AgentCore passerelles Amazon Bedrock d'accéder en toute sécurité aux cibles des passerelles pour le compte des utilisateurs authentifiés et autorisés lors de l'autorisation entrante.

AgentCore Gateway prend en charge les types d'autorisation sortante suivants :

  • Aucune autorisation (déconseillé) — Certains types de cibles vous offrent la possibilité de contourner l'autorisation sortante. Cette option moins sécurisée n'est pas recommandée.

  • IAM-based autorisation sortante  : utilisez le rôle de service de passerelle pour authentifier l'accès à la cible de passerelle avec AWS Signature Version 4 (Sig V4).

  • Informations d'identification IAM de l'appelant  : la passerelle utilise les informations d'identification IAM de l'appelant pour signer les demandes adressées à la cible. La passerelle joue un rôle au nom de l'appelant à l'aide du Service d'accès fédéré (FAS) et signe la demande sortante avec l'identité de l'appelant. Cela est utile lorsque le service cible doit autoriser en fonction de l'identité de l'appelant d'origine plutôt que du rôle du service de passerelle.

  • OAuth  : cadre d'autorisation ouvert qui permet à une application cliente d'accéder aux ressources. Vous pouvez utiliser OAuth avec un fournisseur d'identité intégré ou personnalisé. Pour plus d'informations, consultez OAuth 2.0. Vous pouvez utiliser les types d'autorisations OAuth suivants :

    • Octroi des informations d'identification du client  : Machine-to-machine authentification (également appelée OAuth à deux étapes). L'application cliente accède aux ressources pour le compte de l'application plutôt que pour le compte de l'utilisateur.

    • Octroi de code d'autorisation — User-delegated accès (également appelé OAuth à 3 branches). L'utilisateur autorise l'application cliente à accéder aux ressources en son nom.

    • Octroi d'échange de jetons (On-behalf-of)  : la passerelle échange le jeton d'accès de l'utilisateur entrant contre un nouveau jeton d'accès délimité qui cible une ressource en aval. Le jeton échangé porte à la fois l'identité de l'utilisateur et celle de l'agent, ce qui permet aux services en aval d'appliquer une autorisation précise à chaque saut sans déclencher de flux de consentement supplémentaires. Pour plus d'informations, consultez la section échange de On-behalf-of jetons.

  • Transmission du jeton  : la passerelle transmet le jeton d'autorisation entrant directement à la cible sans modification. Le service cible est chargé de valider le jeton. Cela nécessite que la passerelle utilise l'autorisation AUTHENTICATE_ONLY entrante afin que le jeton soit validé mais préservé pour le transfert.

  • Clé API  : utilisez le AgentCore service pour générer une clé API afin d'authentifier l'accès à la cible de la passerelle.

Le type d'autorisation sortante que vous pouvez configurer dépend du type de cible de passerelle auquel vous autorisez l'accès :

Type de cible Aucune autorisation Rôle du service de passerelle Informations d'identification IAM de l'appelant OAuth (informations d'identification du client) OAuth (code d'autorisation) OAuth (échange de jetons) Transmission de jetons Clé API

Étape API Gateway

Oui

Oui

Non

Non

Non

Non

Non

Oui

Fonction Lambda

Non

Oui

Non

Non

Non

Non

Non

Non

Serveur MCP

Oui

Oui

Non

Oui

Oui

Oui

Non

Oui

Schéma OpenAPI

Oui

Oui

Non

Oui

Oui

Oui

Non

Oui

Schéma de Smithy

Non

Oui

Non

Oui

Non

Non

Non

Non

AgentCore Exécution (HTTP)

Non

Oui

Oui

Oui

Non

Non

Oui

Non
Note

Si vous utilisez un modèle de fournisseur d'intégration comme cible, passez en revue les types d'autorisation pris en charge pour les différents modèles dans les Built-in modèles provenant des fournisseurs d'intégration en tant que cibles.

Avant d'ajouter une cible à votre passerelle, vous devez configurer son autorisation via l'une des méthodes prises en charge.

Note

Vous pouvez ignorer cette condition préalable si vous prévoyez d'utiliser la console de AWS gestion ou l' AgentCore interface de ligne de commande pour créer votre passerelle. Si vous utilisez l'un de ces outils, vous pouvez autoriser la création AgentCore automatique d'un rôle de service pour vous avec les autorisations nécessaires pour accéder à la cible. Chaque fois que vous ajoutez une cible, les autorisations nécessaires sont automatiquement associées à votre rôle de service.

Sélectionnez un sujet pour savoir comment configurer ce type d'autorisation :

Configurer l'autorisation IAM-based sortante avec un rôle de service de passerelle

IAM-based l'autorisation sortante vous permet d'utiliser les informations d'identification IAM du rôle de service de passerelle pour autoriser avec AWS Signature Version 4 (Sig V4). Cette option permet au AgentCore service Amazon Bedrock de s'authentifier auprès des cibles de passerelle au nom des appelants de votre passerelle.

Si vous utilisez cette option, vérifiez que le rôle de service de passerelle dispose bedrock-agentcore:InvokeGateway d'autorisations. La passerelle utilise les informations d'identification du rôle de service pour l'authentification lors de l'invocation.

Configuration supplémentaire pour le serveur MCP et les cibles OpenAPI

Lorsque vous utilisez l'autorisation IAM-based sortante avec un serveur MCP ou une cible OpenAPI, vous devez fournir une configuration supplémentaire pour la signature Sigv4. Dans lecredentialProviderConfigurations, incluez un iamCredentialProvider avec les champs suivants :

  • service (obligatoire) : nom du AWS service utilisé pour la signature SIGv4. Par exemple, bedrock-agentcore pour les serveurs MCP hébergés sur Amazon AgentCore Bedrock.

  • region (facultatif) — La AWS région pour la signature SIGv4. Si vous ne spécifiez pas de région, la passerelle utilise sa propre région.

Pour les cibles Lambda, API Gateway et Smithy, n'incluez pas le iamCredentialProvider champ. Ces types de cibles ne prennent en charge que la GATEWAY_IAM_ROLE configuration de base avec credentialProviderType uniquement. Pour plus d'informations sur la spécification de la configuration du fournisseur d'informations d'identification, consultez la section Autorisation du rôle de service de AgentCore passerelle (IAM).

Meilleures pratiques de sécurité pour l' IAM-based autorisation sortante

Le rôle d'exécution de la passerelle est partagé entre toutes les cibles configurées avecGATEWAY_IAM_ROLE. Ses autorisations constituent la limite supérieure de ce que tout appelant autorisé peut exercer via la passerelle. Suivez ces bonnes pratiques pour limiter l'exposition :

  • Étendez le rôle d'exécution aux autorisations minimales  : accordez uniquement les autorisations nécessaires pour toutes les cibles configurées. Évitez les caractères génériques Action ou Resource les caractères génériques.

  • Utilisez des passerelles distinctes pour différentes limites de confiance  : si les cibles ont des niveaux de sensibilité différents ou s'adressent à des charges de travail différentes, déployez-les derrière des passerelles distinctes avec des rôles d'exécution distincts.

  • Utilisez le moteur de politiques pour restreindre l'accès des appelants — Sur les passerelles partagées, utilisez le moteur de politiques pour contrôler quels appelants peuvent invoquer quelles cibles, en limitant le rayon d'action des autorisations d'un seul appelant.

Configurer l'autorisation sortante avec un client OAuth

Pour configurer l'autorisation sortante avec un client OAuth, vous utilisez le service AgentCore Identity et vous spécifiez les informations d'identification du client que vous recevez lors de la création d'un client dans un fournisseur d'identité intégré (voir Configuration et configuration du fournisseur) ou un fournisseur d'identité personnalisé.

Pour configurer l'autorisation sortante avec un client OAuth

  1. Enregistrez votre application client auprès d'un fournisseur tiers pris en charge.

  2. Vous recevrez un identifiant client, un secret client et éventuellement d'autres valeurs auxquelles vous ferez référence lorsque vous configurerez l'autorisation sortante.

  3. Suivez l'une des étapes ci-dessous, en fonction de vos besoins :

  4. Prenez note de l'ARN d'identification généré (credentialProviderArndans l'API) et de l'ARN secret de AWS Secrets Manager (secretArndans l'API). Vous utiliserez ces valeurs lorsque vous créerez la cible de votre passerelle.

  5. (Si vous utilisez un rôle de service de passerelle personnalisé) Associez la politique basée sur l'identité suivante à votre rôle de service de passerelle :

    {
"Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "GetWorkloadAccessToken",
        "Effect": "Allow",
        "Action": [
            "bedrock-agentcore:GetWorkloadAccessToken",
        ],
        "Resource": [
            "arn:aws:bedrock-agentcore:us-east-1:123456789012:workload-identity-directory/default",
            "arn:aws:bedrock-agentcore:us-east-1:123456789012:workload-identity-directory/default/workload-identity/GatewayName-*"
        ]
      },
      {
        "Sid": "GetResourceOauth2Token",
        "Effect": "Allow",
        "Action": [
            "bedrock-agentcore:GetResourceOauth2Token",
        ],
        "Resource": [
            "arn:aws:bedrock-agentcore:us-east-1:123456789012:token-vault/TokenVaultId/oauth2credentialprovider/CredentialName"
        ]
      },
      {
        "Sid": "GetSecretValue",
        "Effect": "Allow",
        "Action": [
            "secretsmanager:GetSecretValue",
        ],
        "Resource": [
            "arn:aws:secretsmanager:us-east-1:123456789012:secret:SecretId"
        ]
      }
    ]
}

    Remplacez les valeurs des champs suivants :

    • Dans la GetWorkloadAccessToken déclaration, remplacez le nom GatewayName de la Resource liste par le nom de votre passerelle.

    • Dans l'GetResourceOauth2Tokeninstruction, remplacez la valeur de la Resource liste par l'ARN de l'identifiant que vous venez de générer.

    • Dans l'GetSecretValueinstruction, remplacez la valeur de la Resource liste par l'ARN du AWS secret renvoyé dans la réponse lorsque vous avez généré les informations d'identification.

Exemples de configuration de l'autorisation du client OAuth

Les exemples suivants vous montrent comment définir l'autorisation via un client OAuth pour la cible de votre passerelle :

Exemple
AgentCore CLI

  1. Les commandes d'identification AgentCore CLI doivent être exécutées dans un projet agentcore existant. Si vous n'en avez pas encore, créez d'abord un projet avecagentcore create.

    agentcore add credential \
  --name oauth-credential-provider \
  --type oauth \
  --discovery-url <DiscoveryUrl> \
  --client-id <ClientId> \
  --client-secret <ClientSecret>
agentcore deploy
AWS CLI

  1. aws bedrock-agentcore-control create-oauth2-credential-provider \
  --name oauth-credential-provider \
  --credential-provider-vendor CustomOAuth2 \
  --oauth2-provider-config-input '{
    "customOAuth2ProviderConfig": {
      "oauthDiscovery": {
        "discoveryUrl": "<DiscoveryUrl>"
      },
      "clientId": "<ClientId>",
      "clientSecret": "<ClientSecret>"
    }
  }'
Boto3

  1. import boto3

client = boto3.client("bedrock-agentcore-control")

client.create_oauth2_credential_provider(
  name="oauth-credential-provider",
  credentialProviderVendor="CustomOAuth2",
  oauth2ProviderConfigInput={
    "oauthDiscovery": {
      "discoveryUrl": "<DiscoveryUrl>"
    },
    "clientId": "<ClientId>",
    "clientSecret": "<ClientSecret>"
  }
)

Configurer l'autorisation sortante à l'aide d'une clé API

Pour configurer l'autorisation sortante à l'aide d'une clé API, vous utilisez le service AgentCore Identity et vous spécifiez une clé API que vous recevez d'un fournisseur d'identité pris en charge.

Pour configurer l'autorisation sortante avec un client OAuth

  1. Enregistrez votre application client auprès d'un fournisseur tiers pris en charge.

  2. Configurez une clé API pour le service du fournisseur. Prenez note des valeurs suivantes, que vous spécifierez lorsque vous ajouterez la cible de la passerelle :

    • Emplacement des informations d'identification  : indique si la clé API doit être placée dans l'en-tête ou en tant que paramètre de requête.

    • Préfixe du justificatif  : préfixe du justificatif d'identification (ex. Porteur).

  3. Suivez l'une des étapes ci-dessous, en fonction de vos besoins :

  4. Prenez note des valeurs suivantes, que vous spécifierez lorsque vous ajouterez la cible de la passerelle :

    • ARN du fournisseur d'informations d'identification  : nom de ressource Amazon (ARN) généré pour le fournisseur d'informations d'identification.

    • Nom  : nom que vous avez donné à la clé API.

    • ARN secret  : ARN secret de AWS Secrets Manager généré pour la clé API.

  5. (Si vous utilisez un rôle de service de passerelle personnalisé) Associez la politique basée sur l'identité suivante à votre rôle de service de passerelle :

    {
"Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "GetWorkloadAccessToken",
        "Effect": "Allow",
        "Action": [
            "bedrock-agentcore:GetWorkloadAccessToken",
        ],
        "Resource": [
            "arn:aws:bedrock-agentcore:us-east-1:123456789012:workload-identity-directory/default",
            "arn:aws:bedrock-agentcore:us-east-1:123456789012:workload-identity-directory/default/workload-identity/GatewayName-*"
        ]
      },
      {
        "Sid": "GetResourceApiKey",
        "Effect": "Allow",
        "Action": [
            "bedrock-agentcore:GetResourceApiKey",
        ],
        "Resource": [
            "arn:aws:bedrock-agentcore:us-east-1:123456789012:token-vault/TokenVaultId/apikeycredentialprovider/Name"
        ]
      },
      {
        "Sid": "GetSecretValue",
        "Effect": "Allow",
        "Action": [
            "secretsmanager:GetSecretValue",
        ],
        "Resource": [
            "arn:aws:secretsmanager:us-east-1:123456789012:secret:SecretId"
        ]
      }
    ]
}

    Remplacez les valeurs des champs suivants :

    • Dans la GetWorkloadAccessToken déclaration, remplacez le nom GatewayName de la Resource liste par le nom de votre passerelle.

    • Dans l'GetResourceApiKeyinstruction, remplacez la valeur de la Resource liste par l'ARN de l'identifiant que vous venez de générer.

    • Dans l'GetSecretValueinstruction, remplacez la valeur de la Resource liste par l'ARN du AWS secret renvoyé dans la réponse lorsque vous avez généré les informations d'identification.

Exemples de définition d'une clé API

Les exemples suivants vous montrent comment définir une clé d'API pour la cible de votre passerelle :

Exemple
AgentCore CLI

  1. Les commandes d'identification de la AgentCore CLI doivent être exécutées dans un projet agentcore existant. Si vous n'en avez pas encore, créez d'abord un projet avecagentcore create.

    agentcore add credential \
  --name api-key-credential-provider \
  --type api-key \
  --api-key <API_KEY_VALUE>
agentcore deploy
AWS CLI

  1. aws bedrock-agentcore-control create-api-key-credential-provider \
  --name api-key-credential-provider \
  --api-key <API_KEY_VALUE>
Boto3

  1. import boto3

client = boto3.client("bedrock-agentcore-control")

client.create_api_key_credential_provider(
  name="api-key-credential-provider",
  apiKey="<API_KEY_VALUE>"
)