Header-Propagierung mit Gateway
Was ist Weitergabe von Header- und Abfrageparametern
Header-Propagierung bezieht sich auf die systematische Weiterleitung selektiver HTTP-Header von eingehenden Anfragen über Ihr Gateway an konfigurierte Ziele und die selektive Weiterleitung von Antwort-Headern zurück an den Client. Ähnlich wie bei der Header-Propagierung ermöglicht die Weitergabe von Abfrageparametern die Weiterleitung von URL-Abfrageparametern von eingehenden Anfragen an konfigurierte Ziele. Diese Funktion kann für Anwendungsfälle verwendet werden, in denen Sie Kontext-, Authentifizierungs-, Tracing- und andere wichtige Informationen zwischen Client und Zielen austauschen müssen. Die Header auf der Vorabliste, die im Aufruf des Tools zum Aufrufen des Gateways bereitgestellt oder von einem benutzerdefinierten Interceptor-Lambda gesendet wurden, werden an die jeweiligen Ziele weitergeleitet.
Diese Funktion funktioniert nach einem Modell mit geteilter Verantwortung:
-
AWS Die Verantwortung besteht darin, die Header und Abfrageparameter, die Sie für Ihre Ziele zugelassen haben, sicher zu übergeben.
-
Es liegt in Ihrer Verantwortung, Vorsicht walten zu lassen und nur die Header für die Weiterverbreitung auf eine Freigabe zu setzen, die für die Ziele unerlässlich sind, um sicherzustellen, dass sie Ihren Sicherheits- und Funktionsanforderungen entsprechen.
Header-Einschränkungen
Um die Sicherheit zu gewährleisten und die Offenlegung vertraulicher Informationen zu verhindern, sind die folgenden Header eingeschränkt und können nicht für die Weitergabe konfiguriert werden:
|
Autorisierung* |
|
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 |
|
Läuft ab |
|
If-Match |
|
If-Modified-Since |
|
If-None-Match |
|
If-Range |
|
If-Unmodified-Since |
|
Last-Modified |
|
Pragma |
|
Variieren |
|
Connection (Verbindung) |
|
Keep-Alive |
|
Proxy-Connection |
|
Upgrade |
|
Host |
|
User-Agent |
|
Referer |
|
From |
|
Range |
|
Accept-Ranges |
|
Transfer-Encoding |
|
TE |
|
Trailer |
|
Server |
|
Date |
|
Speicherort |
|
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 |
|
Width |
|
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 |
|
: Methode |
|
:Pfad |
|
:Schema |
|
: Autorität |
|
:Status |
|
Link |
|
Sec-WebSocket-Key |
|
Sec-WebSocket-Accept |
|
Sec-WebSocket-Version |
|
Sec-WebSocket-Protocol |
|
Sec-WebSocket-Extensions |
-
Der Autorisierungsheader darf bei der Erstellung des Ziels nicht zugelassen werden. Er wird jedoch an das Ziel weitergeleitet, wenn er von einem Interceptor-Lambda bereitgestellt wird. Einzelheiten finden Sie unter Header-Übertragung von Interceptor-Lambda.
Wichtig
Zusätzlich zu den oben genannten eingeschränkten Headern können Header, die in API-Schlüsseln und im REST-API-Schema bereitgestellt werden, nicht für die Header-Weitergabe konfiguriert werden.
Für zulässige Header gelten zusätzliche Validierungsregeln:
-
Maximal 10 Anforderungsheader, 10 Antwortheader und 10 Abfrageparameter pro Ziel, um Missbrauch zu verhindern und die Leistung aufrechtzuerhalten
-
Header-Namen dürfen nur alphanumerische Zeichen, Bindestriche und Unterstriche (Regex:) enthalten
^[a-zA-Z0-9_-]+$ -
Header-Werte sind auf maximal 4 KB begrenzt, um eine Speichererschöpfung zu vermeiden
-
Header-Werte dürfen nur druckbare ASCII-Zeichen enthalten
-
Kopfzeilen, die mit beginnen,
X-Amzn-sind verboten (mit Ausnahme von -*-Headern X-Amzn-Bedrock-AgentCore-Runtime-Custom)
Konfiguration der Weitergabe von Header- und Abfrageparametern
Sie können Header- und Abfrageparameter auf Zielebene konfigurieren, wenn Sie Gateway-Ziele erstellen oder aktualisieren. Header und Abfrageparameter werden pro Ziel angegeben, sodass sichergestellt wird, dass jedes Ziel nur die Header erhält, die es benötigt.
Target-level Konfiguration
Konfigurieren Sie die Header-Propagierung allowedRequestHeadersallowedResponseHeaders, indem Sie allowedQueryParameters Felder, und zu den Feldern Ihres Ziels hinzufügenmetadataConfiguration:
{ "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" ] } }
Verwenden des Python-SDK:
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'] } )
Header-Weitergabe von Interceptor-Lambda
Wenn Sie benutzerdefinierte Interceptor-Lambdas mit Ihrem Gateway verwenden, können Sie die Header-Übertragung dynamisch steuern, indem Sie Header in Ihre Interceptor-Lambda-Antwort aufnehmen.
So funktioniert die Weitergabe von Interceptor-Headern
Interceptor-Lambdas können die Header-Propagierung auf folgende Weise beeinflussen:
-
Überschreibung des Autorisierungsheaders: Der
AuthorizationHeader der Interceptor-Lambda-Antwort wird automatisch an das Ziel weitergegeben. DerAuthorizationHeader kann zwar nicht in der Zulassungsliste des Ziels konfiguriert werden, er wird jedoch an das Ziel weitergeleitet, wenn er von einem Interceptor-Lambda bereitgestellt wird.Wenn Sie dem Ziel beispielsweise einen Anmeldeinformationsanbieter hinzugefügt haben, der ein Autorisierungstoken wie
Authorization: Bearer client-tokendas Interceptor-Lambda bereitstelltAuthorization: Bearer refreshed-token, wird der WertBearer refreshed-tokenaus dem Interceptor-Lambda an das Ziel weitergeleitet. -
Benutzerdefinierte Header-Injection: Zusätzliche Header aus der Interceptor-Lambda-Antwort werden mit der konfigurierten Ziel-Header-Allowlist zusammengeführt.
-
Header-Priorität: Von Interceptor-Lambda bereitgestellte Header haben im Konfliktfall Vorrang vor vom Client bereitgestellten Headern.
Wenn Sie beispielsweise den Header
x-tenant-idin der Zielkonfiguration zulassen und die eingehende Anfrage liefert,x-tenant-id: tenant-123während das Interceptor-Lambda bereitstellt, wird der Wert aus dem Interceptor-Lambda an das Ziel weitergeleitet.x-tenant-id: tenant-456tenant-456 -
Sicherheitsüberprüfung: Alle von Lambda bereitgestellten Header unterliegen denselben Validierungsregeln wie konfigurierte Header. Mit Ausnahme des Authorization-Headers müssen alle anderen Header bei der Zielerstellung auf eine Zulassungsliste gesetzt werden, damit sie an die Ziele weitergeleitet werden können.
Implementierung der Header-Weitergabe in Interzeptoren
Konfigurieren Sie Ihr Interceptor-Lambda so, dass Header zurückgegeben werden, die an das Ziel weitergegeben werden sollen:
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'] } } }
Zu den häufigsten Anwendungsfällen für die Weitergabe von Interceptor-Headern gehören:
- Abrufen von Anmeldeinformationen
-
Rufen Sie kurzlebige Token aus sicheren Tresoren ab und fügen Sie sie als Autorisierungsheader ein, um zu verhindern, dass Anmeldeinformationen in Client-Anwendungen offengelegt werden.
- Kontext-Injektion
-
Fügen Sie Mandantenkennungen, Organisationskontext oder Benutzerattribute hinzu, die aus authentifizierten Benutzeransprüchen abgeleitet wurden, anstatt den vom Kunden bereitgestellten Werten zu vertrauen.
- Header-Transformation
-
Transformieren oder bereinigen Sie Header auf der Grundlage von Geschäftslogik, Compliance-Anforderungen oder Sicherheitsrichtlinien, bevor sie das Ziel erreichen.
- Dynamisches Routing
-
Fügen Sie Routing-Hinweise, Feature-Flags oder A/B Test-Header ein, die auf einer Echtzeitanalyse der Benutzerattribute oder des Systemstatus basieren.
Sicherheitsüberlegungen
Beachten Sie bei der Implementierung der Header-Weitergabe mit Interceptor-Lambdas die folgenden bewährten Sicherheitsmethoden:
-
Überprüfen Sie die Header-Quellen: Verbreiten Sie nur Header, die explizit in Ihrer Ziel-Allowlist konfiguriert sind oder von vertrauenswürdigen Interceptor-Lambdas zurückgegeben werden
-
Bereinigen Sie vertrauliche Daten: Entfernen oder maskieren Sie personenbezogene Daten und vertrauliche Informationen, bevor Sie Header an externe MCP-Server weiterleiten
-
Verwenden Sie die geringsten Rechte: Konfigurieren Sie Interceptor-Lambda-IAM-Rollen mit minimalen Rechten, die für das Abrufen von Anmeldeinformationen und das Abrufen von Kontexten erforderlich sind
-
Implementieren Sie die Auditprotokollierung: Protokollieren Sie Header-Transformationen und Aktivitäten zum Abrufen von Anmeldeinformationen, um die Sicherheit zu überwachen und die Einhaltung von Vorschriften zu gewährleisten
-
Überprüfen Sie den Header-Inhalt: Stellen Sie sicher, dass von Lambda generierte Header dieselben Validierungsregeln erfüllen wie konfigurierte Header
Bewährte Methoden
Beachten Sie bei der Implementierung der Header-Propagierung die folgenden bewährten Methoden:
- Verwenden Sie eine zielspezifische Konfiguration
-
Konfigurieren Sie Header pro Ziel und nicht global. Verschiedene Ziele erfordern möglicherweise unterschiedliche Header, und eine zielspezifische Konfiguration bietet eine bessere Sicherheitsisolierung.
- Minimiert die Anzahl der Header
-
Verbreiten Sie nur Header, die vom Ziel tatsächlich benötigt werden. Zu viele Header erhöhen die Größe der Anfrage und den Verarbeitungsaufwand.
- Verwenden Sie semantische Header-Namen
-
Wählen Sie aussagekräftige Header-Namen, die eindeutig auf ihren Zweck hinweisen, z. B.
x-correlation-idfür die Nachverfolgung oderx-tenant-idfür Mehrmandantenfähigkeit. - Implementieren Sie die richtige Fehlerbehandlung
-
Behandeln Sie Fälle, in denen erforderliche Header fehlen oder ungültig sind. Überlegen Sie, ob die Anfrage fehlschlagen soll oder ob Sie Standardwerte angeben möchten.
- Überwachen Sie die Header-
-
Verwenden Sie Gateway-Observability-Funktionen, um zu überwachen, welche Header weitergegeben werden, und um Probleme bei der Überprüfung oder Verarbeitung von Headern zu identifizieren.
- Testen Sie die Header-Weitergabe
-
Stellen Sie sicher, dass die Header während der Entwicklung und beim Testen korrekt an Ihre Ziele weitergegeben werden. Verwenden Sie Tools wie Anforderungsprotokollierung oder Debugging-Endpunkte, um den Header-Flow zu validieren.