使用 Gateway 進行標頭傳播
什麼是標頭和查詢參數傳播
標頭傳播是指透過閘道從傳入請求到已設定目標的選擇性 HTTP 標頭的系統性轉送,以及將回應標頭的選擇性轉送回用戶端。與標頭傳播類似,查詢參數傳播可讓 URL 查詢參數從傳入請求轉送到設定的目標。此功能可用於您需要在用戶端和目標之間交換內容、身分驗證、追蹤和其他重要資訊的使用案例。呼叫工具呼叫閘道或從自訂攔截器 lambda 傳送的預先允許清單標頭,將會轉送至特定目標。
此功能做為共同責任模型運作:
-
AWS 責任是安全地傳遞您已針對目標列入允許清單的標頭和查詢參數。
-
您的責任是謹慎行事,並只允許列出對目標至關重要的傳播標頭,以確保它們符合您的安全和功能需求。
標頭限制
為了維護安全性並防止暴露敏感資訊,下列標頭受到限制,且無法設定為傳播:
|
授權* |
|
Proxy-Authorization |
|
WWW-Authenticate |
|
接受 |
|
Accept-Charset |
|
接受編碼 |
|
Accept-Language |
|
內容類型 |
|
內容長度 |
|
Content-Encoding |
|
Content-Language |
|
Content-Location |
|
內容範圍 |
|
快取控制 |
|
ETag |
|
到期 |
|
If-Match |
|
If-Modified-Since |
|
If-None-Match |
|
If-Range |
|
If-Unmodified-Since |
|
Last-Modified |
|
Pragma |
|
不同 |
|
連線 |
|
Keep-Alive |
|
Proxy-Connection |
|
升級 |
|
主機 |
|
使用者代理程式 |
|
Referer |
|
從 |
|
範圍 |
|
Accept-Ranges |
|
Transfer-Encoding |
|
TE |
|
預告片 |
|
Server |
|
日期 |
|
Location |
|
重試後 |
|
Set-Cookie |
|
Cookie |
|
Content-Security-Policy |
|
Content-Security-Policy-Report-Only |
|
Strict-Transport-Security |
|
X-Content-Type-Options |
|
X-Frame-Options |
|
X-XSS-Protection |
|
推薦網站政策 |
|
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 |
|
檢視區寬度 |
|
下行 |
|
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 |
|
:方法 |
|
:path |
|
:結構描述 |
|
:授權 |
|
:狀態 |
|
連結 |
|
Sec-WebSocket-Key |
|
Sec-WebSocket-Accept |
|
Sec-WebSocket-Version |
|
Sec-WebSocket-Protocol |
|
Sec-WebSocket-Extensions |
-
無法在目標建立期間允許列出授權標頭。不過,當攔截器 lambda 提供時,它會轉送到目標。如需詳細資訊,請參閱攔截器 lambda 中的標頭傳播。
重要
除了上述的限制標頭之外,API 金鑰和 REST API 結構描述中提供的標頭無法設定為標頭傳播。
其他驗證規則適用於允許的標頭:
-
每個目標最多 10 個請求標頭、10 個回應標頭和 10 個查詢參數,以防止濫用和維護效能
-
標頭名稱只能包含英數字元、連字號和底線
^[a-zA-Z0-9_-]+$(regex:) -
標頭值上限為 4KB,以防止記憶體耗盡
-
標頭值只能包含可列印的 ASCII 字元
-
X-Amzn-禁止使用開頭為 的標頭 (X-Amzn-Bedrock-AgentCore-Runtime-Custom-* 標頭除外)
設定標頭和查詢參數傳播
您可以在建立或更新閘道目標時,在目標層級設定標頭和查詢參數。每個目標指定標頭和查詢參數,確保每個目標僅接收所需的標頭。
目標層級組態
將 allowedRequestHeaders 、 allowedResponseHeaders 和 allowedQueryParameters 欄位新增至目標的 ,以設定標頭傳播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" ] } }
使用 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'] } )
攔截器 lambda 的標頭傳播
搭配閘道使用自訂攔截器 lambda 時,您可以在攔截器 lambda 回應中包含標頭,以動態控制標頭傳播。
攔截器標頭傳播的運作方式
攔截器 lambda 可以透過下列方式影響標頭傳播:
-
授權標頭覆寫:來自攔截器 lambda 回應的
Authorization標頭會自動傳播到目標。雖然無法在目標的允許清單中設定標頭,但當攔截器 lambda 提供時,該Authorization標頭會轉送至目標。例如,如果您已將登入資料提供者新增至提供類似 授權字符的目標,
Authorization: Bearer client-token且攔截器 lambda 提供Authorization: Bearer refreshed-token,Bearer refreshed-token則來自攔截器 lambda 的值將轉送至目標。 -
自訂標頭注入:來自攔截器 lambda 回應的其他標頭會與設定的目標標頭允許清單合併。
-
標頭優先順序:發生衝突時,攔截器 lambda 提供的標頭優先於用戶端提供的標頭。
例如,如果您在目標組態
x-tenant-id中允許清單標頭,而傳入請求在攔截器 lambda 提供x-tenant-id: tenant-456x-tenant-id: tenant-123時提供 ,tenant-456則來自攔截器 lambda 的值將轉送至目標。 -
安全驗證:所有 lambda 提供的標頭都必須遵守與設定標頭相同的驗證規則。除了授權標頭之外,所有其他標頭都必須在目標建立期間列入允許清單,才能轉送至目標。
在攔截器中實作標頭傳播
設定您的攔截器 lambda 以傳回應傳播至目標的標頭:
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'] } } }
攔截器標頭傳播的常見使用案例包括:
- 登入資料擷取
-
從安全保存庫擷取短期權杖,並將其插入為授權標頭,以防止用戶端應用程式中的憑證公開。
- 內容注入
-
新增租戶識別符、組織內容或衍生自已驗證使用者宣告的使用者屬性,而不是信任用戶端提供的值。
- 標頭轉換
-
根據業務邏輯、合規要求或安全政策,在標頭到達目標之前進行轉換或清理。
- 動態路由
-
根據使用者屬性或系統狀態的即時分析,注入路由提示、功能旗標或 A/B 測試標頭。
安全考量
使用攔截器 lambda 實作標頭傳播時,請遵循下列安全最佳實務:
-
驗證標頭來源:僅傳播在目標允許清單中明確設定或由受信任攔截器 lambda 傳回的標頭
-
清理敏感資料:在將標頭轉送至外部 MCP 伺服器之前,移除或遮罩 PII 和敏感資訊
-
使用最低權限:使用最低許可設定攔截器 lambda IAM 角色,以擷取登入資料和擷取內容所需的最低許可
-
實作稽核記錄:日誌標頭轉換和憑證擷取活動,以進行安全性監控和合規
-
驗證標頭內容:確保 lambda 產生的標頭符合與設定的標頭相同的驗證規則
最佳實務
實作標頭傳播時,請遵循下列最佳實務:
- 使用目標特定的組態
-
為每個目標設定標頭,而不是全域設定。不同的目標可能需要不同的標頭,而目標特定的組態可提供更好的安全隔離。
- 最小化標頭計數
-
僅傳播目標實際需要的標頭。標頭過多會增加請求大小和處理開銷。
- 使用語意標頭名稱
-
選擇可清楚指出其用途的描述性標頭名稱,例如
x-correlation-id用於追蹤或x-tenant-id多租用戶。 - 實作適當的錯誤處理
-
處理必要標頭遺失或無效的案例。考慮是否失敗請求或提供預設值。
- 監控標頭用量
-
使用閘道可觀測性功能來監控哪些標頭正在傳播,並識別標頭驗證或處理的任何問題。
- 測試標頭傳播
-
確認標頭在開發和測試期間正確傳播到您的目標。使用請求記錄或偵錯端點等工具來驗證標頭流程。