Configurer l'autorisation entrante pour votre passerelle

Avant de créer votre passerelle, vous devez configurer l'autorisation entrante. L'autorisation entrante valide les utilisateurs qui tentent d'accéder à des cibles via votre AgentCore passerelle. AgentCore prend en charge les types d'autorisation entrante suivants :

Si vous ne prévoyez pas d'utiliser la configuration d'autorisation par défaut à l'aide d'Amazon Cognito, sélectionnez la rubrique correspondant au type d'autorisation que vous prévoyez d'utiliser pour savoir comment la configurer :

IAM-based autorisation entrante

IAM-based L'autorisation entrante vous permet d'utiliser les informations d'identification IAM de l'appelant passerelle pour l'autorisation. Vous pouvez utiliser cette option si vous souhaitez créer une identité IAM grâce à laquelle les utilisateurs qui appellent votre passerelle peuvent être authentifiés.

Pour configurer l'autorisation IAM-based entrante

Exemple de stratégie

L'exemple suivant montre une politique que vous pouvez associer à une identité pour lui permettre d'invoquer une passerelle avec l'ID my-gateway-12345

{
"Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowGatewayInvocation",
      "Effect": "Allow",
      "Action": [
        "bedrock-agentcore:InvokeGateway"
      ],
      "Resource": [
        "arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/my-gateway-12345"
      ]
    }
  ]
}

Ressources

Autorisation entrante basée sur un jeton Web JSON (JWT)

Un jeton Web JSON (JWT) est un jeton sécurisé et compact utilisé pour l'autorisation. Vous pouvez créer un JWT avec un fournisseur d'identité compatible. Après avoir créé un JWT, vous pouvez le récupérer et le spécifier comme configuration d'autorisation lorsque vous créez la passerelle.

Vous pouvez utiliser la AgentCore CLI pour configurer un JWT par défaut ou en créer un manuellement avec un fournisseur d'identité compatible. Pour en savoir plus sur les différentes méthodes de configuration d'un JWT, sélectionnez l'une des rubriques suivantes :

Configurer un JWT par défaut

La AgentCore CLI vous permet de créer facilement une configuration d'autorisation par défaut à l'aide d'Amazon Cognito, que vous pouvez ensuite utiliser lors de la création d'une passerelle. Lorsque vous exécutezagentcore create, la CLI vous invite à configurer l'autorisation entrante et peut configurer automatiquement un groupe d'utilisateurs Amazon Cognito pour vous.

agentcore create

Une fois la commande terminée, la AgentCore CLI fournit des informations d'authentification et d'autorisation :

Configurer un JWT manuellement

Amazon Bedrock AgentCore prend en charge les JWT de tous les fournisseurs d'identité. Vous pouvez voir quelques exemples dans Configuration et configuration du fournisseur.

Lors de la création du JWT, prenez note des valeurs suivantes, que vous renseignerez CustomJWTAuthorizerConfigurationlorsque vous créerez une passerelle, si elles s'appliquent à votre cas d'utilisation :

Vous aurez besoin de ces valeurs pour effectuer les opérations suivantes :

Portez la publicité sur les défis liés à l'authentification

Lorsqu'un client envoie une demande à une JWT-authorized passerelle sans jeton d'accès valide, la passerelle renvoie une réponse d'erreur avec un WWW-Authenticate en-tête qui indique les étendues OAuth requises. Cela suit le format de défi de jetons RFC 6750 Bearer et permet aux MCP-compliant clients de découvrir automatiquement les étendues nécessaires à l'acquisition de jetons.

La passerelle renvoie les réponses suivantes en fonction de l'erreur :

La scope valeur contient les étendues délimitées par des espaces configurées comme étendues autorisées dans celles de la passerelle. CustomJWTAuthorizerConfiguration La resource_metadata valeur pointe vers le document de métadonnées des ressources protégées OAuth de la passerelle/.well-known/oauth-protected-resource, que les clients peuvent récupérer pour découvrir le serveur d'autorisation et les étendues prises en charge.

Utiliser un fournisseur d'identité privé (VPC-hosted)

AgentCore Gateway prend en charge JWT-based l'autorisation entrante auprès des fournisseurs d'identité hébergés au sein de votre VPC. Vous pouvez configurer un privateEndpoint sur le customJWTAuthorizer pour permettre d'accéder AgentCore à vos points de terminaison OIDC privés, à votre jeton et à vos points de terminaison JWKS sans les exposer à l'Internet public.

Votre principal IAM doit disposer de l'iam:CreateServiceLinkedRoleautorisation nécessaire pour identity-network.bedrock-agentcore.amazonaws.com qu' AgentCore Identity puisse créer le rôle AWSServiceRoleForBedrockAgentCoreIdentity lié au service en votre nom s'il n'existe pas déjà.

privateEndpointCela s'applique au domaine dans lediscoveryUrl. Si votre fournisseur d'identité utilise des domaines différents pour les autres points de terminaison (par exemple, le jeton ou le point de terminaison JWKS renvoie à un domaine différent de celui de l'URL de découverte), utilisez cette option privateEndpointOverrides pour spécifier une configuration de point de terminaison privé distincte pour chaque domaine supplémentaire.

L'exemple suivant crée une passerelle avec un fournisseur d'identité privé à l'aide de Lattice géré :

{
  "name": "my-private-idp-gateway",
  "protocolType": "MCP",
  "roleArn": "arn:aws:iam::123456789012:role/my-gateway-role",
  "authorizerType": "CUSTOM_JWT",
  "authorizerConfiguration": {
    "customJWTAuthorizer": {
      "allowedAudience": [
        "my-audience"
      ],
      "discoveryUrl": "https://my-idp.internal.example.com/.well-known/openid-configuration",
      "privateEndpoint": {
        "managedVpcResource": {
          "vpcIdentifier": "vpc-0abc123def456",
          "subnetIds": ["subnet-0abc123", "subnet-0def456"],
          "endpointIpAddressType": "IPV4",
          "securityGroupIds": ["sg-0abc123def"]
        }
      }
    }
  }
}

Si votre jeton ou vos points de terminaison JWKS utilisent un domaine différent de celui de l'URL de découverte, ajoutez une privateEndpointOverrides entrée pour chaque domaine supplémentaire. Actuellement, n'privateEndpointOverridesest pris en charge qu'avec des ressources Lattice autogérées :

{
  ...
  "authorizerConfiguration": {
    "customJWTAuthorizer": {
      "allowedAudience": ["my-audience"],
      "discoveryUrl": "https://my-idp.internal.example.com/.well-known/openid-configuration",
      "privateEndpoint": {
        "selfManagedLatticeResource": {
          "resourceConfigurationIdentifier": "arn:aws:vpc-lattice:us-east-1:123456789012:resourceconfiguration/rcfg-abc123"
        }
      },
      "privateEndpointOverrides": [
        {
          "domain": "my-token-server.internal.example.com",
          "privateEndpoint": {
            "selfManagedLatticeResource": {
              "resourceConfigurationIdentifier": "arn:aws:vpc-lattice:us-east-1:123456789012:resourceconfiguration/rcfg-def456"
            }
          }
        }
      ]
    }
  }
}

Pour en savoir plus sur Lattice autogéré, les configurations entre comptes et les configurations avancées, voir Se connecter aux ressources privées de votre VPC à l'aide de VPC Lattice. Pour un guide complet couvrant les scénarios d'IdP privés entrants et sortants, voir Connect to private identity providers.

Autorisation entrante déchargée

Dans le cas d'une autorisation entrante déchargée, la passerelle ne prend aucune décision d'autorisation de son propre chef. Au lieu de cela, il transfère l'autorisation à un autre composant :

AgentCore propose deux types de déchargement :

Quel que soit le type, vous décidez où l'autorisation est réellement appliquée :

Authenticate-only autorisation

Avec l'autorisation d'authentification uniquement (AUTHENTICATE_ONLY), la passerelle vérifie la signature Signature Version 4 (SigV4) de l'appelant pour confirmer son identité, mais ne prend aucune décision d'autorisation de son propre chef. Tout principal IAM authentifié peut invoquer la passerelle indépendamment de ses autorisations, et la demande est transmise à la cible. L'autorisation est déléguée au service cible en aval ou à un moteur de politiques rattaché à la passerelle.

Aucune autorisation

Vous pouvez créer une passerelle configurée sans autorisation en utilisantauthorizerType=NONE. La passerelle n'effectuera aucune autorisation sur la demande de passerelle entrante et la demande peut être non authentifiée.

Bonnes pratiques en matière de sécurité

Intégrer un environnement d'exécution existant sans modifier son authentification

Lorsque vous associez un type d'entrée déchargé à un type d'autorisation sortant correspondant qui transmet l'identité de l'appelant au moteur d'exécution, l'intégration à une passerelle peut être aussi simple que de définir une dérogation de point de terminaison sur votre client existant, aucune modification d'authentification n'est requise :