HTTP em Ascensão: Telemetria, Rastreamento e Terror em Ambientes de Contêineres

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

O HTTP está em toda parte. Sua televisão fala HTTP. Seu celular. Seu tablet. Seu carro. Se é um dispositivo conectado à rede, provavelmente fala HTTP com a mesma fluência com que você fala seu idioma nativo.

O HTTP é bastante flexível. Ao contrário de seus vizinhos de rede — TCP e IP —, ele praticamente não tem limites quanto às informações que pode transportar do ponto A ao ponto B. Enquanto o IP e o TCP precisam seguir padrões muito rígidos e inflexíveis, que definem — até o último bit — quais valores podem ser usados, o HTTP adota uma abordagem mais livre em relação aos dados que transporta. Texto. Binário. JSON. XML. Criptografado. Texto simples.

Assim como o ratel, o HTTP não está nem aí. Ele transporta de tudo – e muito mais.

Uma das maneiras pelas quais o HTTP demonstra constantemente sua, bem, flexibilidade está nos cabeçalhos que os usuários raramente veem. Esses são os metadados transportados por cada solicitação e resposta HTTP. Eles compartilham de tudo: do tipo e tamanho do conteúdo a tokens de autorização e rastros que revelam quem você é e por onde andou — quer você queira ou não.

É importante observar isso porque, como vimos no universo dos contêineres, os cabeçalhos HTTP vêm ganhando espaço não apenas como um mecanismo para transportar dados entre clientes e serviços, mas também como um meio de compartilhar os metadados que permitem que esses ambientes dinâmicos sejam dimensionados com tanta eficiência.

Um conceito que vem ganhando destaque é o de malha de serviços e, com ele, a adição de cabeçalhos HTTP personalizados que transportam informações operacionais. Este blog da Buoyant – a empresa por trás de uma das duas principais implementações de malha de serviços de código aberto – demonstra a dependência de cabeçalhos HTTP para compartilhar a telemetria necessária à correlação de rastreamentos, o que ajuda a simplificar o conjunto altamente complexo de transações entre serviços que compõem um único par de solicitação e resposta HTTP.

Para quem não tiver interesse em ler todo o post mencionado acima, aqui está o trecho mais relevante — os destaques são meus:

Embora nós, da Buoyant, gostemos de descrever todos os dados adicionais de rastreamento fornecidos pelo linkerd como “pitadas mágicas de telemetria para microsserviços”, a realidade é que precisamos de uma pequena quantidade de contexto da requisição para interligar os rastreamentos. Esse contexto é estabelecido quando o linkerd recebe uma requisição e, no caso de requisições HTTP, é transmitido por meio de cabeçalhos HTTP quando o linkerd encaminha a requisição para a sua aplicação. Para que a sua aplicação preserve o contexto da requisição, ela precisa incluir, sem modificações, todos os cabeçalhos HTTP de entrada l5d-ctx-* em todas as requisições de saída que fizer.

Vale observar que os cabeçalhos HTTP personalizados mencionados são apenas alguns dos vários usados para compartilhar telemetria nesses sistemas altamente distribuídos. Conforme observado no blog, o cabeçalho l5d-sample pode ser usado para ajustar as taxas de amostragem de rastreamento. Portanto, ele não é usado apenas para compartilhar informações, mas também para proporcionar controle operacional sobre o sistema.

Reflita sobre isso por um momento. Os cabeçalhos HTTP são usados para controlar o comportamento de sistemas operacionais. Lembre-se disso, pois será importante daqui a alguns parágrafos.

Em vez de separar o plano de controle do plano de dados, neste caso ambos os planos são transportados simultaneamente, e cabe aos endpoints separar, por assim dizer, a forma da função. Como essa solução específica se baseia no conceito de malha de serviços — em que todas as solicitações de entrada e saída de um serviço passam por um proxy —, isso é relativamente fácil de fazer. O proxy pode filtrar os cabeçalhos HTTP operacionais e agir de acordo com eles antes de encaminhar a solicitação (ou resposta) ao destinatário pretendido. Ele também pode adicionar instruções operacionais e inserir dados de telemetria para ajudar a correlacionar os rastreamentos posteriormente.

As redes de aplicações também estão se tornando comuns em ambientes de contêineres. Embora sempre tenham existido (pelo menos para nós que atuamos no mundo dos proxies programáveis), agora vêm ganhando cada vez mais espaço à medida que cresce a necessidade de maior flexibilidade. Em essência, os controladores de ingresso são proxies programáveis que permitem o roteamento com base não apenas em endereços IP ou FQDNs, mas também em dados específicos da aplicação, geralmente transportados em cabeçalhos HTTP. Versionamento, direcionamento, escalabilidade. Todas essas funções de um controlador de ingresso são viabilizadas pelo HTTP e por sua indiferença em relação aos cabeçalhos HTTP.

Infelizmente, os cabeçalhos HTTP também constituem, por si só, um vetor de ataque. Portanto, cabe a nós considerar cuidadosamente as implicações de depender dos cabeçalhos HTTP não apenas para compartilhar dados operacionais, mas também para controlar o comportamento operacional. Os cabeçalhos HTTP são um curinga (falando sério, leia a BNF) e são, por natureza, universalmente baseados em texto. Isso faz com que sejam não apenas fáceis de modificar, mas também de manipular para transportar comandos maliciosos, que são processados por um número cada vez maior de dispositivos e sistemas intermediários e de endpoint.

Se isso não o apavora, você não tem prestado atenção.

Felizmente, o uso de cabeçalhos HTTP como método tanto do plano de controle quanto do plano de dados limita-se principalmente a sistemas conteinerizados. Isso significa que eles geralmente ficam protegidos por trás de vários pontos de controle voltados ao público, que permitem às organizações mitigar a ameaça decorrente de sua natureza excessivamente permissiva. Uma abordagem arquitetural que incorpore um caminho de entrada seguro (norte-sul) pode fornecer a proteção necessária contra explorações. Não, ainda não vimos ninguém tentar fazer isso. Mas já vimos violações demais causadas por cabeçalhos HTTP, então é melhor prevenir do que remediar.

O HTTP está se consolidando não apenas como o principal protocolo para aplicativos, serviços e dispositivos, mas também para telemetria, rastreamento e transporte de comandos operacionais. É um momento empolgante, mas precisamos contrabalançar esse pensamento de “podemos fazer qualquer coisa” com “mas vamos fazer isso com segurança” se quisermos evitar desastres operacionais.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie