Propagation d'en-têtes avec Gateway
Qu'est-ce que la propagation des paramètres d'en-tête et de requête
La propagation des en-têtes fait référence au transfert systématique des en-têtes HTTP sélectifs des demandes entrantes via votre passerelle vers des cibles configurées, ainsi qu'au transfert sélectif des en-têtes de réponse au client. Tout comme la propagation des en-têtes, la propagation des paramètres de requête permet de transférer les paramètres de requête URL des demandes entrantes vers des cibles configurées. Cette fonctionnalité peut être utilisée dans les cas d'utilisation où vous devez échanger des informations de contexte, d'authentification, de suivi et d'autres informations critiques entre le client et les cibles. Les en-têtes pré-autorisés fournis lors de l'appel de l'outil d'appel à la passerelle ou envoyés par l'intercepteur personnalisé Lambda seront transmis aux cibles spécifiques.
Cette fonctionnalité fonctionne comme un modèle de responsabilité partagée :
-
AWS la responsabilité est de transmettre en toute sécurité les en-têtes et les paramètres de requête que vous avez autorisés à attribuer à vos cibles.
-
Il est de votre responsabilité de faire preuve de prudence et de n'autoriser la propagation que des en-têtes essentiels aux cibles, en vous assurant qu'ils répondent à vos exigences de sécurité et de fonctionnalité.
Restrictions d'en-tête
Pour garantir la sécurité et empêcher la divulgation d'informations sensibles, les en-têtes suivants sont restreints et ne peuvent pas être configurés pour la propagation :
|
Autorisation* |
|
Proxy-Authorization |
|
WWW-Authenticate |
|
Accept |
|
Accept-Charset |
|
Accept-Encoding |
|
Accept-Language |
|
Content-Type |
|
Content-Length |
|
Content-Encoding |
|
Content-Language |
|
Content-Location |
|
Content-Range |
|
Cache-Control |
|
ETag |
|
Expires |
|
If-Match |
|
If-Modified-Since |
|
If-None-Match |
|
If-Range |
|
If-Unmodified-Since |
|
Last-Modified |
|
Pragma |
|
Varier |
|
Connexion |
|
Keep-Alive |
|
Proxy-Connection |
|
Upgrade |
|
Host (Hôte) |
|
User-Agent |
|
Référent |
|
De |
|
Range |
|
Accept-Ranges |
|
Transfer-Encoding |
|
TE |
|
Trailer |
|
Serveur |
|
Date |
|
Location |
|
Retry-After |
|
Set-Cookie |
|
Cookie |
|
Content-Security-Policy |
|
Content-Security-Policy-Report-Only |
|
Strict-Transport-Security |
|
X-Content-Type-Options |
|
X-Frame-Options |
|
X-XSS-Protection |
|
Referrer-Policy |
|
Permissions-Policy |
|
Cross-Origin-Embedder-Policy |
|
Cross-Origin-Opener-Policy |
|
Cross-Origin-Resource-Policy |
|
Access-Control-Allow-Origin |
|
Access-Control-Allow-Methods |
|
Access-Control-Allow-Headers |
|
Access-Control-Allow-Credentials |
|
Access-Control-Expose-Headers |
|
Access-Control-Max-Age |
|
Access-Control-Request-Method |
|
Access-Control-Request-Headers |
|
Origin |
|
Accept-CH |
|
Accept-CH-Lifetime |
|
RPD |
|
Width |
|
Viewport-Width |
|
Liaison descendante |
|
ECT |
|
RTT |
|
Save-Data |
|
Clear-Site-Data |
|
Feature-Policy |
|
Expect-CT |
|
Public-Key-Pins |
|
Public-Key-Pins-Report-Only |
|
X-Forwarded-For |
|
X-Forwarded-Host |
|
X-Forwarded-Proto |
|
X-Real-IP |
|
X-Requested-With |
|
X-CSRF-Token |
|
CF-Ray |
|
CF-Connecting-IP |
|
X-Amz-Cf-Id |
|
X-Cache |
|
X-Served-By |
|
:méthode |
|
:chemin |
|
:schéma |
|
:autorité |
|
:statut |
|
Lien |
|
Sec-WebSocket-Key |
|
Sec-WebSocket-Accept |
|
Sec-WebSocket-Version |
|
Sec-WebSocket-Protocol |
|
Sec-WebSocket-Extensions |
-
L'en-tête d'autorisation ne peut pas être autorisé lors de la création de la cible. Cependant, il sera transmis à la cible lorsqu'il sera fourni par un intercepteur lambda. Voir Propagation d'en-têtes depuis l'intercepteur Lambda pour plus de détails.
Important
Outre les en-têtes restreints mentionnés ci-dessus, les en-têtes fournis dans les clés d'API et le schéma d'API REST ne peuvent pas être configurés pour la propagation des en-têtes.
Des règles de validation supplémentaires s'appliquent aux en-têtes autorisés :
-
Maximum de 10 en-têtes de demande, 10 en-têtes de réponse et 10 paramètres de requête par cible pour éviter les abus et maintenir les performances
-
Les noms d'en-tête ne doivent contenir que des caractères alphanumériques, des traits d'union et des traits de soulignement (regex :)
^[a-zA-Z0-9_-]+$ -
Les valeurs d'en-tête sont limitées à 4 Ko maximum pour éviter l'épuisement de la mémoire
-
Les valeurs d'en-tête ne doivent contenir que des caractères ASCII imprimables
-
Les en-têtes commençant par
X-Amzn-sont interdits (à l'exception des en-têtes X-Amzn-Bedrock-AgentCore-Runtime-Custom -*)
Configuration de la propagation des paramètres d'en-tête et de requête
Vous pouvez configurer les paramètres d'en-tête et de requête au niveau de la cible lors de la création ou de la mise à jour des cibles de passerelle. Les en-têtes et les paramètres de requête sont spécifiés par cible, ce qui garantit que chaque cible ne reçoit que les en-têtes dont elle a besoin.
Target-level configuration
Configurez la propagation des en-têtes en ajoutant allowedRequestHeadersallowedResponseHeaders, et allowedQueryParameters des champs à ceux de votre cible metadataConfiguration :
{ "name": "my-target", "description": "my target description", "credentialProviderConfigurations": [{ "credentialProviderType": "OAUTH", "credentialProvider": { "oauthCredentialProvider": { "providerArn": "arn:aws:bedrock-agentcore:us-west-2:123456789012:credential-provider/example", "scopes": [] } } }], "targetConfiguration": { "mcp": { "mcpServer": { "endpoint": "https://example.com/mcp" } } }, "metadataConfiguration": { "allowedRequestHeaders": [ "request-header" ], "allowedResponseHeaders": [ "response-header" ], "allowedQueryParameters": [ "query-param" ] } }
À l'aide du SDK Python :
import boto3 # Initialize the client client = boto3.client('bedrock-agentcore', region_name='us-west-2') # Create target with header propagation response = client.create_gateway_target( gatewayId='gateway-123', name='mcp-target-with-headers', description='MCP target with header propagation', targetConfiguration={ 'mcp': { 'mcpServer': { 'endpoint': 'https://example.com/mcp' } } }, metadataConfiguration={ 'allowedRequestHeaders': ['x-correlation-id', 'x-tenant-id'], 'allowedResponseHeaders': ['x-rate-limit-remaining'], 'allowedQueryParameters': ['version'] } )
Propagation d'en-têtes depuis l'intercepteur Lambda
Lorsque vous utilisez des lambdas d'interception personnalisés avec votre passerelle, vous pouvez contrôler dynamiquement la propagation des en-têtes en incluant des en-têtes dans la réponse lambda de l'intercepteur.
Comment fonctionne la propagation des en-têtes de l'intercepteur
Les lambdas de l'intercepteur peuvent influencer la propagation des en-têtes de la manière suivante :
-
Annulation de l'en-tête d'autorisation : l'
Authorizationen-tête de la réponse lambda de l'intercepteur est automatiquement propagé à la cible. Bien que l'Authorizationen-tête ne puisse pas être configuré dans la liste d'autorisation de la cible, il sera transmis à la cible lorsqu'il sera fourni par un intercepteur lambda.Par exemple, si vous avez ajouté un fournisseur d'informations d'identification à la cible qui fournit un jeton d'autorisation tel que celui
Authorization: Bearer client-tokenfourni par l'intercepteur lambdaAuthorization: Bearer refreshed-token, la valeurBearer refreshed-tokende l'intercepteur lambda sera transmise à la cible. -
Injection d'en-têtes personnalisée : les en-têtes supplémentaires issus de la réponse lambda de l'intercepteur sont fusionnés avec la liste d'autorisation d'en-têtes cibles configurée.
-
Priorité des en-têtes : les en-têtes fournis par Interceptor Lambda ont priorité sur les en-têtes fournis par le client en cas de conflit.
Par exemple, si vous autorisez l'en-tête de liste
x-tenant-iddans la configuration cible et que la demande entrante fournitx-tenant-id: tenant-123alors que l'intercepteur lambda le fournitx-tenant-id: tenant-456, la valeurtenant-456de l'intercepteur lambda sera transmise à la cible. -
Validation de sécurité : tous les en-têtes fournis par Lambda sont soumis aux mêmes règles de validation que les en-têtes configurés. À l'exception de l'en-tête Authorization, tous les autres en-têtes doivent être autorisés lors de la création des cibles pour qu'ils soient transmis aux cibles.
Implémentation de la propagation d'en-tête dans les intercepteurs
Configurez votre intercepteur lambda pour renvoyer des en-têtes qui doivent être propagés à la cible :
import json import boto3 def lambda_handler(event, context): # Extract request context request_context = event.get('requestContext', {}) user_identity = request_context.get('identity', {}) # Fetch credentials from secure store (example) credentials_client = boto3.client('secretsmanager') secret = credentials_client.get_secret_value( SecretId=f"mcp-credentials/{user_identity.get('userId')}" ) credentials = json.loads(secret['SecretString']) # Return response with headers to propagate return { "interceptorOutputVersion": "1.0", "mcp": { "transformedGatewayRequest": { "headers": { # Authorization header will be propagated automatically "Authorization": f"Bearer {credentials['access_token']}", # Custom headers (must be in target allowlist) "x-tenant-id": user_identity.get('tenantId'), "x-correlation-id": request_context.get('requestId') }, "body": event['mcp']['gatewayRequest']['body'] } } }
Les cas d'utilisation courants pour la propagation d'en-têtes d'intercepteur incluent :
- Récupération des informations d'identification
-
Récupérez des jetons de courte durée dans des coffres-forts sécurisés et injectez-les sous forme d'en-têtes d'autorisation, afin d'éviter que les informations d'identification ne soient exposées dans les applications clientes.
- Injection de contexte
-
Ajoutez des identifiants de locataire, un contexte organisationnel ou des attributs utilisateur dérivés de demandes d'utilisateurs authentifiées plutôt que de vous fier aux valeurs fournies par le client.
- Transformation de l'en-tête
-
Transformez ou nettoyez les en-têtes en fonction de la logique métier, des exigences de conformité ou des politiques de sécurité avant qu'ils n'atteignent la cible.
- Routage dynamique
-
Injectez des indices de routage, des indicateurs de fonctionnalité ou des en-têtes de A/B test basés sur une analyse en temps réel des attributs utilisateur ou de l'état du système.
Considérations sur la sécurité
Lorsque vous implémentez la propagation d'en-têtes avec des intercepteurs lambdas, suivez les meilleures pratiques de sécurité suivantes :
-
Valider les sources d'en-têtes : ne propagez que les en-têtes explicitement configurés dans votre liste d'autorisation cible ou renvoyés par Trusted Interceptor Lambdas
-
Nettoyez les données sensibles : supprimez ou masquez les informations personnelles et sensibles avant de transférer les en-têtes vers des serveurs MCP externes
-
Utiliser le moindre privilège : configurez les rôles IAM Lambda d'interception avec des autorisations minimales requises pour la récupération des informations d'identification et la récupération du contexte
-
Mettre en œuvre la journalisation des audits : enregistrez les transformations des en-têtes et les activités de récupération des informations d'identification pour la surveillance de la sécurité et la conformité
-
Valider le contenu des en-têtes : assurez-vous que les en-têtes générés par lambda répondent aux mêmes règles de validation que les en-têtes configurés
Bonnes pratiques
Suivez les meilleures pratiques suivantes lors de la mise en œuvre de la propagation des en-têtes :
- Utiliser une configuration spécifique à la cible
-
Configurez les en-têtes par cible plutôt que globalement. Différentes cibles peuvent nécessiter des en-têtes différents, et la configuration spécifique à la cible fournit une meilleure isolation de sécurité.
- Réduisez le nombre d'en-têtes
-
Propagez uniquement les en-têtes réellement nécessaires à la cible. Les en-têtes excessifs augmentent la taille des demandes et la charge de traitement.
- Utiliser des noms d'en-têtes sémantiques
-
Choisissez des noms d'en-tête descriptifs qui indiquent clairement leur objectif, par exemple
x-correlation-idpour le suivi oux-tenant-idpour la mutualisation. - Mettre en œuvre une gestion appropriée des erreurs
-
Gérez les cas où les en-têtes requis sont manquants ou non valides. Déterminez s'il convient d'échouer à la demande ou de fournir des valeurs par défaut.
- Surveiller l'utilisation des en-têtes
-
Utilisez les fonctionnalités d'observabilité de la passerelle pour surveiller les en-têtes propagés et identifier les problèmes liés à la validation ou au traitement des en-têtes.
- Tester la propagation des en-têtes
-
Vérifiez que les en-têtes sont correctement propagés à vos cibles pendant le développement et les tests. Utilisez des outils tels que la journalisation des demandes ou le débogage des points de terminaison pour valider le flux d'en-têtes.