View a markdown version of this page

Configurer l'autorisation sortante pour votre passerelle - Amazon Bedrock 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é d'API

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 de passerelle 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 (non recommandée) : certains types de cibles vous offrent la possibilité de contourner les autorisations sortantes. Cette option moins sûre 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 la 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 Federated Access Service (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 à des ressources. Vous pouvez utiliser OAuth avec un fournisseur d'identité intégré ou avec un fournisseur 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 connue sous le nom d'OAuth à 2 pattes). L'application cliente accède aux ressources pour le compte de l'application plutôt que pour le compte de l'utilisateur.

    • Octroi du code d'autorisation — User-delegated accès (également connu sous le nom d'OAuth à 3 étapes). L'utilisateur consent à ce que l'application cliente accède 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.

  • Transfert de jetons : 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 conservé pour le transfert.

  • Clé d'API — Utilisez le AgentCore service pour générer une clé d'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) Transfert 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 Smithy

Non

Oui

Non

Oui

Non

Non

Non

Non

AgentCore Temps d'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 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 AWS de gestion ou la AgentCore CLI pour créer votre passerelle. Si vous utilisez l'un de ces outils, vous pouvez créer AgentCore automatiquement 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 une rubrique 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 la 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 s'authentifier 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) — Le 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) — 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 champ. iamCredentialProvider 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).

Bonnes pratiques de sécurité pour les autorisations IAM-based sortantes

Le rôle d'exécution de la passerelle est partagé entre toutes les cibles configurées avecGATEWAY_IAM_ROLE. Ses autorisations sont 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 à toutes les cibles configurées. Évitez les caractères généraux Action ou Resource les caractères génériques.

  • Utilisez des passerelles distinctes pour des limites de confiance différentes : si les cibles ont des niveaux de sensibilité différents ou servent des charges de travail différentes, déployez-les derrière des passerelles distinctes dotées de 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, limitant ainsi le rayon d'action des autorisations de chaque 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 dans un fournisseur d'identité personnalisé.

Pour configurer l'autorisation sortante avec un client OAuth

  1. Enregistrez votre application cliente auprès d'un fournisseur tiers compatible.

  2. Vous recevrez un identifiant client, un secret client et éventuellement d'autres valeurs auxquelles vous ferez référence lors de la configuration de l'autorisation de sortie.

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

    • Pour configurer l'autorisation sortante dans la console à l'aide d'un fournisseur d'identité intégré, suivez les étapes de la section Ajouter un client OAuth à l'aide du fournisseur inclus.

    • Pour configurer l'autorisation sortante dans la console à l'aide d'un fournisseur d'identité personnalisé, suivez les étapes de la section Ajouter un client OAuth à l'aide d'un fournisseur personnalisé.

    • Pour configurer l'autorisation sortante à l'aide de l'API, envoyez un CreateOauth2CredentialProvideravec l'un des points de terminaison du plan de AgentCore contrôle. Pour des exemples, voir Exemples de définition de l'autorisation du client OAuth.

      Note

      La forme de l'objet JSON auquel le oauth2ProviderConfigInput champ correspond dépend du fournisseur que vous utilisez et doit être conforme à la credentialProviderVendor valeur que vous spécifiez. Pour voir des exemples de différentes configurations pour différents fournisseurs d'informations d'identification, consultez les exemples d'autorisation sortante fournis par le fournisseur d'informations d'identification de votre choix dans Configuration et configuration du fournisseur.

  4. Prenez note de l'ARN d'identification généré (credentialProviderArndans l'API) et de l'ARN secret du AWS Secrets Manager (secretArndans l'API). Vous utiliserez ces valeurs lorsque vous créerez votre cible de 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 l'GetWorkloadAccessTokeninstruction, remplacez le GatewayName dans 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 définition de l'autorisation du client OAuth

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

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 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é d'API

Pour configurer l'autorisation sortante avec une clé d'API, vous utilisez le service AgentCore Identity et spécifiez une clé d'API que vous recevez d'un fournisseur d'identité compatible.

Pour configurer l'autorisation sortante avec un client OAuth

  1. Enregistrez votre application cliente auprès d'un fournisseur tiers compatible.

  2. Configurez une clé d'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é d'API doit être placée dans l'en-tête ou en tant que paramètre de requête.

    • Préfixe d'identification — Le préfixe de l'identifiant (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 — Le nom que vous avez donné à la clé d'API.

    • Secret ARN — Un ARN secret du AWS Secrets Manager généré pour la clé d'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 l'GetWorkloadAccessTokeninstruction, remplacez le GatewayName dans 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é d'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>"
)