Propagação de cabeçalho com Gateway
O que é propagação de cabeçalhos e parâmetros de consulta
A propagação do cabeçalho se refere ao encaminhamento sistemático de cabeçalhos HTTP seletivos das solicitações recebidas por meio do gateway para destinos configurados e ao encaminhamento seletivo dos cabeçalhos de resposta de volta ao cliente. Semelhante à propagação de cabeçalho, a propagação de parâmetros de consulta permite o encaminhamento de parâmetros de consulta de URL das solicitações recebidas para destinos configurados. Esse recurso pode ser usado para casos de uso em que você precisa trocar contexto, autenticação, rastreamento e outras informações críticas entre o cliente e os destinos. Os cabeçalhos pré-permitidos fornecidos na chamada da ferramenta de invocação para o gateway ou enviados pelo interceptor personalizado lambda serão encaminhados para os alvos específicos.
Esse recurso funciona como um modelo de responsabilidade compartilhada:
-
AWS a responsabilidade é passar com segurança os cabeçalhos e os parâmetros de consulta que você listou como permitidos para seus destinos.
-
Sua responsabilidade é ter cuidado e permitir apenas os cabeçalhos para propagação que são essenciais para os alvos, garantindo que eles atendam aos seus requisitos funcionais e de segurança.
restrições de cabeçalho
Para manter a segurança e evitar a exposição de informações confidenciais, os cabeçalhos a seguir são restritos e não podem ser configurados para propagação:
|
Autorização* |
|
Proxy-Authorization |
|
WWW-Authenticate |
|
Aceitar |
|
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 |
|
Variar |
|
Conexão |
|
Keep-Alive |
|
Proxy-Connection |
|
Upgrade |
|
Host |
|
User-Agent |
|
Referer |
|
De |
|
Intervalo |
|
Accept-Ranges |
|
Transfer-Encoding |
|
TE |
|
Trailer |
|
Servidor |
|
Data |
|
Local |
|
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 |
|
Origem |
|
Accept-CH |
|
Accept-CH-Lifetime |
|
DPR |
|
Largura |
|
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 |
|
:método |
|
:caminho |
|
:esquema |
|
:autoridade |
|
:status |
|
Link |
|
Sec-WebSocket-Key |
|
Sec-WebSocket-Accept |
|
Sec-WebSocket-Version |
|
Sec-WebSocket-Protocol |
|
Sec-WebSocket-Extensions |
-
O cabeçalho de autorização não pode ser incluído na lista de permissões durante a criação do destino. No entanto, ele será encaminhado para o alvo quando fornecido por um interceptor lambda. Consulte Propagação do cabeçalho do interceptor lambda para obter detalhes.
Importante
Além dos cabeçalhos restritos mencionados acima, os cabeçalhos fornecidos nas chaves de API e no esquema da API REST não podem ser configurados para propagação de cabeçalhos.
Regras de validação adicionais se aplicam aos cabeçalhos permitidos:
-
Máximo de 10 cabeçalhos de solicitação, 10 cabeçalhos de resposta e 10 parâmetros de consulta por destino para evitar abusos e manter o desempenho
-
Os nomes dos cabeçalhos devem conter somente caracteres alfanuméricos, hífens e sublinhados (regex:)
^[a-zA-Z0-9_-]+$ -
Os valores do cabeçalho são limitados a um máximo de 4 KB para evitar o esgotamento da memória
-
Os valores do cabeçalho devem conter somente caracteres ASCII imprimíveis
-
Cabeçalhos que começam com
X-Amzn-são proibidos (exceto para cabeçalhos X-Amzn-Bedrock-AgentCore-Runtime-Custom -*)
Configurando a propagação do cabeçalho e dos parâmetros de consulta
Você pode configurar parâmetros de cabeçalho e consulta no nível de destino ao criar ou atualizar destinos de gateway. Os cabeçalhos e os parâmetros de consulta são especificados por destino, garantindo que cada destino receba somente os cabeçalhos de que precisa.
Target-level configuração
Configure a propagação do cabeçalho adicionando allowedRequestHeadersallowedResponseHeaders,, e allowedQueryParameters campos aos do metadataConfiguration seu destino:
{ "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 o SDK do 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'] } )
Propagação do cabeçalho a partir do interceptor lambda
Ao usar lambdas de interceptores personalizados com seu gateway, você pode controlar dinamicamente a propagação do cabeçalho incluindo cabeçalhos na resposta lambda do interceptor.
Como funciona a propagação do cabeçalho do interceptor
Os lambdas do Interceptor podem influenciar a propagação do cabeçalho das seguintes maneiras:
-
Substituição do cabeçalho de autorização: o
Authorizationcabeçalho da resposta lambda do interceptor é propagado automaticamente para o destino. Embora oAuthorizationcabeçalho não possa ser configurado na lista de permissões do alvo, ele será encaminhado para o alvo quando fornecido por um interceptor lambda.Por exemplo, se você adicionou um provedor de credenciais ao destino que fornece um token de autorização como
Authorization: Bearer client-tokene o interceptor lambda forneceAuthorization: Bearer refreshed-token, o valorBearer refreshed-tokendo interceptor lambda será encaminhado para o destino. -
Injeção de cabeçalho personalizado: cabeçalhos adicionais da resposta lambda do interceptor são mesclados com a lista de permissões do cabeçalho de destino configurada.
-
Precedência do cabeçalho: os cabeçalhos fornecidos pelo Interceptor lambda têm precedência sobre os cabeçalhos fornecidos pelo cliente em caso de conflitos.
Por exemplo, se você permitir o cabeçalho da lista de permissões
x-tenant-idna configuração de destino e a solicitação recebida fornecerx-tenant-id: tenant-123enquanto o interceptor lambda fornecex-tenant-id: tenant-456, o valortenant-456do interceptor lambda será encaminhado para o destino. -
Validação de segurança: todos os cabeçalhos fornecidos pelo lambda estão sujeitos às mesmas regras de validação dos cabeçalhos configurados. Com exceção do cabeçalho de autorização, todos os outros cabeçalhos devem estar na lista de permissões durante a criação do destino para que sejam encaminhados aos destinos.
Implementando a propagação de cabeçalhos em interceptores
Configure seu interceptor lambda para retornar cabeçalhos que devem ser propagados para o destino:
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'] } } }
Casos de uso comuns para propagação de cabeçalhos de interceptores incluem:
- Busca de credenciais
-
Recupere tokens de curta duração de cofres seguros e injete-os como cabeçalhos de autorização, evitando a exposição de credenciais em aplicativos clientes.
- Injeção de contexto
-
Adicione identificadores de inquilinos, contexto organizacional ou atributos de usuário derivados de declarações de usuários autenticados em vez de confiar nos valores fornecidos pelo cliente.
- transformação do cabeçalho
-
Transforme ou limpe os cabeçalhos com base na lógica de negócios, nos requisitos de conformidade ou nas políticas de segurança antes que eles atinjam a meta.
- Roteamento dinâmico
-
Injete dicas de roteamento, sinalizadores de recursos ou cabeçalhos de A/B teste com base na análise em tempo real dos atributos do usuário ou do estado do sistema.
Considerações sobre segurança
Ao implementar a propagação do cabeçalho com lambdas do interceptor, siga estas melhores práticas de segurança:
-
Validar fontes de cabeçalho: propague somente cabeçalhos que estejam explicitamente configurados em sua lista de permissões de destino ou retornados pelo interceptor confiável lambdas
-
Limpe dados confidenciais: remova ou mascare PII e informações confidenciais antes de encaminhar cabeçalhos para servidores MCP externos
-
Use o mínimo de privilégios: configure as funções do interceptor lambda IAM com o mínimo de permissões necessárias para busca de credenciais e recuperação de contexto
-
Implemente o registro de auditoria: transformações de cabeçalhos de registros e atividades de busca de credenciais para monitoramento de segurança e conformidade
-
Valide o conteúdo do cabeçalho: garanta que os cabeçalhos gerados pelo lambda atendam às mesmas regras de validação dos cabeçalhos configurados
Práticas recomendadas
Siga estas melhores práticas ao implementar a propagação de cabeçalhos:
- Use a configuração específica do alvo
-
Configure cabeçalhos por destino em vez de globalmente. Alvos diferentes podem exigir cabeçalhos diferentes, e a configuração específica do alvo fornece melhor isolamento de segurança.
- Minimize a contagem de cabe
-
Propague somente cabeçalhos que sejam realmente necessários para o destino. Cabeçalhos excessivos aumentam o tamanho da solicitação e a sobrecarga de processamento.
- Use nomes de cabeçalhos semânticos
-
Escolha nomes de cabeçalhos descritivos que indiquem claramente sua finalidade, como
x-correlation-idpara rastreamento oux-tenant-idmultilocação. - Implemente o tratamento adequado de erros
-
Lide com casos em que os cabeçalhos necessários estão ausentes ou são inválidos. Considere se a solicitação deve falhar ou fornecer valores padrão.
- Monitore o uso do cabe
-
Use os recursos de observabilidade do gateway para monitorar quais cabeçalhos estão sendo propagados e identificar quaisquer problemas com a validação ou o processamento do cabeçalho.
- Propagação do cabeçalho de teste
-
Verifique se os cabeçalhos foram propagados corretamente para seus destinos durante o desenvolvimento e o teste. Use ferramentas como registro de solicitações ou endpoints de depuração para validar o fluxo do cabeçalho.