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

O HTTP é onipresente. Sua televisão fala HTTP. Seu telefone. Seu tablet. Seu carro. Se for um dispositivo com rede, ele provavelmente fala HTTP tão fluentemente quanto você fala sua língua nativa.

HTTP é algo flexível. Ao contrário de seus vizinhos de rede – TCP e IP – ele é quase ilimitado nas informações que pode transportar do ponto A ao ponto B. Enquanto o IP e o TCP são obrigados a aderir a padrões muito rígidos e inflexíveis que definem – ao bit – quais valores podem ser usados, o HTTP adota uma abordagem laissez-faire para os dados que transporta. Texto. Binário. JSON. XML. Criptografado. Texto simples.

Assim como o texugo-do-mel, o HTTP não se importa. Ele carregará tudo isso – e muito mais.

Uma das maneiras pelas quais o HTTP está constantemente exibindo sua flexibilidade é em seus cabeçalhos raramente vistos pelos usuários. Esses são os metadados transportados por cada solicitação e resposta HTTP. Ele compartilha tudo, desde o tipo de conteúdo até o comprimento do conteúdo, tokens de autorização e breadcrumbs que informam quem você é e onde você esteve — quer você queira ou não.

É importante observar isso porque, como vimos no espaço de contêineres, os cabeçalhos HTTP estão crescendo como um mecanismo não apenas para transportar dados entre clientes e serviços, mas como um meio de compartilhar os metadados que fazem esses ambientes de movimentação rápida escalarem de forma tão eficiente.

De importância crescente é a noção de malha de serviço e, com ela, 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ço de código aberto – ilustra a dependência de cabeçalhos HTTP para compartilhamento de telemetria necessária para permitir a correlação de rastros que ajudam 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 aqueles que não estão interessados em ler todo o blog acima mencionado, aqui está a parte mais relevante – o destaque é meu:

Embora nós da Buoyant gostemos de descrever todos os dados de rastreamento adicionais que o linkerd fornece como "sorvetes mágicos de telemetria para microsserviços", a realidade é que precisamos de uma pequena quantidade de contexto de solicitação para conectar os rastreamentos. Esse contexto de solicitação é estabelecido quando o linkerd recebe uma solicitação e, para solicitações HTTP, ele é passado por meio de cabeçalhos HTTP quando o linkerd envia a solicitação por proxy para seu aplicativo. Para que seu aplicativo preserve o contexto da solicitação, ele precisa incluir, sem modificação, todos os cabeçalhos HTTP l5d-ctx-* de entrada em quaisquer solicitações de saída que ele fizer.

Vale ressaltar que os cabeçalhos HTTP personalizados referenciados são apenas um 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 taxas de amostragem de rastreamento. Portanto, ele não está sendo usado apenas para compartilhar informações, mas também para fornecer controle operacional sobre o sistema .

Pense nisso por um momento. Cabeçalhos HTTP são usados para controlar o comportamento de sistemas operacionais. Lembre-se disso, será importante em 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 pontos finais separar a forma da função, por assim dizer. Como essa solução específica depende de um conceito de malha de serviço – no qual cada solicitação de entrada e saída de um serviço passa por um proxy – isso é facilmente realizado. O proxy pode filtrar os cabeçalhos HTTP operacionais e agir sobre eles antes de encaminhar a solicitação (ou resposta) ao destinatário pretendido. Ele também pode adicionar quaisquer instruções operacionais, bem como inserir telemetria para ajudar a corresponder os rastros posteriormente.

A rede de aplicativos também está se tornando algo comum em ambientes de contêineres. Embora sempre tenha sido uma coisa (pelo menos para aqueles de nós no mundo dos proxies programáveis), agora está aumentando com maior frequência à medida que a necessidade de maior flexibilidade cresce. Os controladores de entrada são, em sua essência, proxies programáveis que permitem o roteamento com base não apenas em endereços IP ou FQDNs, mas em dados específicos do aplicativo, mais comumente transportados por cabeçalhos HTTP. Controle de versão, direcionamento, dimensionamento. Todas essas funções de um controlador de entrada são possíveis graças ao HTTP e sua atitude indiferente em relação aos cabeçalhos HTTP.

Infelizmente, os cabeçalhos HTTP também são seu próprio vetor de ataque. Cabe a nós, então, considerar cuidadosamente as ramificações de confiar em cabeçalhos HTTP não apenas para compartilhar dados operacionais, mas também para controlar o comportamento operacional. Cabeçalhos HTTP são um curinga (sério, leia o BNF) que são universalmente baseados em texto por natureza. Isso os torna não apenas fáceis de modificar, mas também de manipular para transportar comandos maliciosos que são consumidos por um número crescente de dispositivos e sistemas intermediários e de endpoint.

Se isso não te assusta, você não estava prestando atenção.

Felizmente, o uso de cabeçalhos HTTP como método de controle e plano de dados é limitado principalmente a sistemas em contêineres. Isso significa que eles geralmente ficam escondidos atrás de vários pontos de controle públicos que oferecem às organizações a capacidade de mitigar a ameaça de sua natureza excessivamente generosa. Uma abordagem arquitetônica que combina um caminho de entrada seguro (norte-sul) pode fornecer a proteção necessária contra exploração. Não, não vimos ninguém tentar isso. Ainda. Mas já vimos tantas violações por causa dos cabeçalhos HTTP que é melhor prevenir do que remediar.

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