Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Propagazione degli header con Gateway
Cos'è la propagazione dei parametri di intestazione e interrogazione
La propagazione delle intestazioni si riferisce all'inoltro sistematico di intestazioni HTTP selettive dalle richieste in arrivo attraverso il gateway alle destinazioni configurate e all'inoltro selettivo delle intestazioni di risposta al client. Analogamente alla propagazione delle intestazioni, la propagazione dei parametri di query consente l'inoltro dei parametri delle query URL dalle richieste in arrivo alle destinazioni configurate. Questa funzionalità può essere utilizzata per i casi d'uso in cui è necessario scambiare contesto, autenticazione, tracciamento e altre informazioni critiche tra client e destinazioni. Le intestazioni preconsentite fornite nella chiamata dello strumento invoke al gateway o inviate dall'interceptor lambda personalizzato verranno inoltrate ai target specifici.
Questa funzionalità funziona come un modello di responsabilità condivisa:
-
AWS la responsabilità è trasmettere in modo sicuro le intestazioni e i parametri di interrogazione consentiti per i tuoi obiettivi.
-
È tua responsabilità fare attenzione e inserire nella lista consentita solo le intestazioni per la propagazione che sono essenziali per le destinazioni, assicurandoti che soddisfino i tuoi requisiti di sicurezza e funzionali.
Restrizioni relative alle intestazioni
Per mantenere la sicurezza e prevenire l'esposizione di informazioni sensibili, le seguenti intestazioni sono limitate e non possono essere configurate per la propagazione:
|
Autorizzazione* |
|
Proxy-Authorization |
|
WWW-Authenticate |
|
Accettare |
|
Accept-Charset |
|
Accept-Encoding |
|
Accept-Language |
|
Content-Type |
|
Content-Length |
|
Content-Encoding |
|
Content-Language |
|
Content-Location |
|
Content-Range |
|
Cache-Control |
|
ETag |
|
Scade |
|
If-Match |
|
If-Modified-Since |
|
If-None-Match |
|
If-Range |
|
If-Unmodified-Since |
|
Last-Modified |
|
Pragma |
|
Variare |
|
Connessione |
|
Keep-Alive |
|
Proxy-Connection |
|
Upgrade |
|
Host |
|
User-Agent |
|
Referente |
|
Da |
|
Intervallo |
|
Accept-Ranges |
|
Transfer-Encoding |
|
TE |
|
Trailer |
|
Server |
|
Data |
|
Location (Ubicazione) |
|
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 |
|
DPR |
|
Larghezza |
|
Viewport-Width |
|
Downlink |
|
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 |
|
:metodo |
|
:percorso |
|
:schema |
|
:autorità |
|
:stato |
|
Link |
|
Sec-WebSocket-Key |
|
Sec-WebSocket-Accept |
|
Sec-WebSocket-Version |
|
Sec-WebSocket-Protocol |
|
Sec-WebSocket-Extensions |
-
L'intestazione di autorizzazione non può essere inserita nell'elenco consentito durante la creazione del target. Tuttavia, verrà inoltrato al bersaglio quando fornito da un intercettore lambda. Per i dettagli, vedere Propagazione dell'intestazione dall'interceptor lambda.
Importante
Oltre alle intestazioni limitate menzionate sopra, le intestazioni fornite nelle chiavi API e nello schema API REST non possono essere configurate per la propagazione delle intestazioni.
Alle intestazioni consentite si applicano regole di convalida aggiuntive:
-
Massimo 10 intestazioni di richiesta, 10 intestazioni di risposta e 10 parametri di query per destinazione per prevenire abusi e mantenere le prestazioni
-
I nomi delle intestazioni devono contenere solo caratteri alfanumerici, trattini e trattini bassi (regex:)
^[a-zA-Z0-9_-]+$ -
I valori delle intestazioni sono limitati a un massimo di 4 KB per evitare l'esaurimento della memoria
-
I valori dell'intestazione devono contenere solo caratteri ASCII stampabili
-
Le intestazioni che iniziano con
X-Amzn-sono proibite (ad eccezione delle intestazioni -*) X-Amzn-Bedrock-AgentCore-Runtime-Custom
Configurazione della propagazione degli header e dei parametri di interrogazione
È possibile configurare i parametri di intestazione e query a livello di destinazione durante la creazione o l'aggiornamento delle destinazioni dei gateway. Le intestazioni e i parametri di interrogazione vengono specificati per destinazione, assicurando che ogni destinazione riceva solo le intestazioni necessarie.
Target-level configurazione
Configura la propagazione dell'header aggiungendo allowedRequestHeadersallowedResponseHeaders, e allowedQueryParameters campi a quelli del tuo target: 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" ] } }
Usando l'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'] } )
Propagazione dell'intestazione dall'interceptor lambda
Quando si utilizzano interceptor lambda personalizzati con il gateway, è possibile controllare dinamicamente la propagazione degli header includendo gli header nella risposta interceptor lambda.
Come funziona la propagazione degli header tramite interceptor
I lambda Interceptor possono influenzare la propagazione dell'header nei seguenti modi:
-
Sostituzione dell'intestazione dell'autorizzazione: l'
Authorizationintestazione della risposta lambda dell'interceptor viene propagata automaticamente alla destinazione. Sebbene l'Authorizationintestazione non possa essere configurata nella lista consentita del target, verrà inoltrata al target quando fornita da un interceptor lambda.Ad esempio, se hai aggiunto al target un provider di credenziali che fornisce un token di autorizzazione simile
Authorization: Bearer client-tokena quello fornito dall'interceptor lambdaAuthorization: Bearer refreshed-token, il valore dell'interceptor lambda verrà inoltrato al target.Bearer refreshed-token -
Iniezione di intestazione personalizzata: le intestazioni aggiuntive della risposta lambda dell'interceptor vengono unite all'header di destinazione allowlist configurato.
-
Precedenza delle intestazioni: le intestazioni fornite da Interceptor lambda hanno la precedenza sulle intestazioni fornite dal client in caso di conflitti.
Ad esempio, se si consente l'intestazione della lista nella configurazione di destinazione e la richiesta
x-tenant-idin arrivo viene fornitax-tenant-id: tenant-123mentre l'interceptor lambda lo fornisce, il valore dell'interceptor lambda verrà inoltrato alla destinazione.x-tenant-id: tenant-456tenant-456 -
Convalida di sicurezza: tutte le intestazioni fornite da lambda sono soggette alle stesse regole di convalida delle intestazioni configurate. Ad eccezione dell'intestazione Authorization, tutte le altre intestazioni devono essere consentite durante la creazione del target per essere inoltrate alle destinazioni.
Implementazione della propagazione degli header negli intercettori
Configura il tuo interceptor lambda per restituire le intestazioni che devono essere propagate al target:
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'] } } }
I casi d'uso più comuni per la propagazione degli header degli interceptor includono:
- Recupero delle credenziali
-
Recupera i token di breve durata dai depositi sicuri e inseriscili come intestazioni di autorizzazione, impedendo l'esposizione delle credenziali nelle applicazioni client.
- Iniezione di contesto
-
Aggiungi identificatori del tenant, contesto organizzativo o attributi utente derivati da dichiarazioni utente autenticate anziché affidarti ai valori forniti dal cliente.
- Trasformazione dell'intestazione
-
Trasforma o disinfetta le intestazioni in base alla logica aziendale, ai requisiti di conformità o alle politiche di sicurezza prima che raggiungano l'obiettivo.
- Routing dinamico
-
Inserisci suggerimenti di routing, flag di funzionalità o intestazioni di A/B test in base all'analisi in tempo reale degli attributi dell'utente o dello stato del sistema.
Considerazioni relative alla sicurezza
Quando implementi la propagazione degli header con interceptor lambda, segui queste best practice di sicurezza:
-
Convalida le fonti delle intestazioni: propaga solo le intestazioni configurate in modo esplicito nella lista consentita di destinazione o restituite da interceptor lambda affidabili
-
Disinfetta i dati sensibili: rimuovi o maschera le PII e le informazioni sensibili prima di inoltrare le intestazioni a server MCP esterni
-
Usa il privilegio minimo: configura i ruoli IAM interceptor lambda con autorizzazioni minime richieste per il recupero delle credenziali e il recupero del contesto
-
Implementa la registrazione di controllo: trasformazioni delle intestazioni dei log e attività di recupero delle credenziali per il monitoraggio della sicurezza e la conformità
-
Convalida il contenuto dell'intestazione: assicurati che le intestazioni generate da lambda soddisfino le stesse regole di convalida delle intestazioni configurate
Best practice
Segui queste best practice quando implementi la propagazione delle intestazioni:
- Utilizza una configurazione specifica per la destinazione
-
Configura le intestazioni per destinazione anziché globalmente. Destinazioni diverse possono richiedere intestazioni diverse e la configurazione specifica della destinazione offre un migliore isolamento di sicurezza.
- Ridurre al minimo il numero di intestazioni
-
Propaga solo le intestazioni effettivamente necessarie alla destinazione. Le intestazioni eccessive aumentano le dimensioni delle richieste e il sovraccarico di elaborazione.
- Usa nomi di intestazione semantici
-
Scegli nomi di intestazione descrittivi che ne indichino chiaramente lo scopo, ad esempio per il tracciamento o
x-correlation-idper la multitenancy.x-tenant-id - Implementa una corretta gestione degli errori
-
Gestisci i casi in cui le intestazioni obbligatorie sono mancanti o non valide. Valuta se non rispondere alla richiesta o fornire valori predefiniti.
- Monitora l'utilizzo dell'intestazione
-
Utilizza le funzionalità di osservabilità del gateway per monitorare quali intestazioni vengono propagate e identificare eventuali problemi con la convalida o l'elaborazione delle intestazioni.
- Verifica la propagazione degli header
-
Verifica che le intestazioni siano propagate correttamente ai tuoi obiettivi durante lo sviluppo e il test. Usa strumenti come la registrazione delle richieste o il debug degli endpoint per convalidare il flusso degli header.