HTTP en auge: telemetría, seguimiento y terror en entornos de contenedores

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

HTTP está en todas partes. Tu televisor habla HTTP. Tu teléfono. Tu tableta. Tu coche. Si es un dispositivo con conexión a la red, probablemente hable HTTP con tanta fluidez como tú hablas tu lengua materna.

HTTP es muy flexible. A diferencia de sus vecinos de red —TCP e IP—, prácticamente no tiene límites en cuanto a la información que puede transportar del punto A al punto B. Mientras que IP y TCP deben cumplir normas muy estrictas e inflexibles que definen, hasta el último bit, qué valores pueden utilizarse, HTTP adopta un enfoque más permisivo respecto a los datos que transporta. Texto. Binario. JSON. XML. Cifrado. Texto sin formato.

Como al tejón de la miel, a HTTP le da igual. Lo transportará todo, y mucho más.

Una de las formas en que HTTP hace gala constantemente de su, bueno, flexibilidad es mediante sus cabeceras, que los usuarios rara vez ven. Se trata de los metadatos que transportan todas las solicitudes y respuestas HTTP. Comparten de todo, desde el tipo y la longitud del contenido hasta los tokens de autorización y las migas de pan que revelan quién eres y dónde has estado, quieras o no.

Es importante señalarlo porque, como hemos visto en el ámbito de los contenedores, las cabeceras HTTP se utilizan cada vez más no solo como mecanismo para transportar datos entre clientes y servicios, sino también como medio para compartir los metadatos que permiten que estos entornos tan dinámicos escalen con tanta eficiencia.

Cada vez cobra más relevancia el concepto de malla de servicios y, con él, la incorporación de cabeceras HTTP personalizadas que contienen información operativa. Este blog de Buoyant —la empresa responsable de una de las dos principales implementaciones de código abierto de mallas de servicios— muestra la dependencia de las cabeceras HTTP para compartir la telemetría necesaria para correlacionar trazas, lo que ayuda a simplificar el complejo conjunto de transacciones entre servicios que conforman un único par de solicitud y respuesta HTTP.

Para quienes no estén interesados en leer íntegramente el blog mencionado anteriormente, este es el fragmento más relevante; el resaltado es mío:

Aunque en Buoyant nos gusta describir todos los datos de seguimiento adicionales que proporciona linkerd como «polvos mágicos de telemetría para microservicios», la realidad es que necesitamos una pequeña cantidad de contexto de la solicitud para enlazar las trazas. Este contexto se establece cuando linkerd recibe una solicitud y, en el caso de las solicitudes HTTP, se transmite mediante cabeceras HTTP cuando linkerd redirige la solicitud a tu aplicación. Para que tu aplicación conserve el contexto de la solicitud, debe incluir, sin modificar, todas las cabeceras HTTP entrantes l5d-ctx-* en cualquier solicitud saliente que realice.

Cabe señalar que las cabeceras HTTP personalizadas mencionadas son solo uno de los diversos mecanismos utilizados para compartir datos de telemetría en estos sistemas altamente distribuidos. Como se indica en el blog, la cabecera l5d-sample puede utilizarse para ajustar las tasas de muestreo del rastreo. Por tanto, no solo se utiliza para compartir información, sino también para proporcionar control operativo sobre el sistema.

Deténgase un momento a pensar en ello. Las cabeceras HTTP se utilizan para controlar el comportamiento de los sistemas operativos. Recuerde esto, será importante dentro de un par de párrafos.

En lugar de separar el plano de control del plano de datos, en este caso ambos planos se transportan simultáneamente y corresponde a los puntos finales separar, por así decirlo, la forma de la función. Dado que esta solución concreta se basa en el concepto de malla de servicios —en el que todas las solicitudes entrantes y salientes de un servicio pasan por un proxy—, esto resulta bastante sencillo. El proxy puede filtrar las cabeceras HTTP operativas y actuar en función de ellas antes de reenviar la solicitud (o respuesta) a su destinatario previsto. También puede añadir instrucciones operativas e insertar datos de telemetría para facilitar la correlación posterior de las trazas.

Las redes de aplicaciones también son cada vez más habituales en los entornos de contenedores. Aunque siempre han existido (al menos para quienes nos movemos en el mundo de los proxies programables), ahora se utilizan con mayor frecuencia a medida que aumenta la necesidad de una mayor flexibilidad. En esencia, los controladores de entrada son proxies programables que permiten enrutar no solo en función de direcciones IP o FQDN, sino también de datos específicos de la aplicación, que suelen transmitirse mediante cabeceras HTTP. Control de versiones, direccionamiento y escalado. Todas estas funciones de un controlador de entrada son posibles gracias a HTTP y a su indiferencia respecto a las cabeceras HTTP.

Lamentablemente, los encabezados HTTP también constituyen por sí mismos un vector de ataque. Por tanto, debemos considerar detenidamente las consecuencias de confiar en ellos no solo para compartir datos operativos, sino también para controlar el comportamiento operativo. Los encabezados HTTP admiten prácticamente cualquier contenido (en serio, lea la BNF) y son siempre de naturaleza textual. Esto hace que no solo sean fáciles de modificar, sino también de manipular para que transporten comandos maliciosos que son procesados por un número cada vez mayor de dispositivos y sistemas intermedios y finales.

Si eso no te aterroriza, es que no has estado prestando atención.

Por suerte, el uso de cabeceras HTTP como método tanto para el plano de control como para el de datos se limita principalmente a los sistemas en contenedores. Esto significa que, por lo general, están ocultas tras varios puntos de control de acceso público que permiten a las organizaciones mitigar la amenaza derivada de su naturaleza excesivamente permisiva. Un enfoque arquitectónico que incorpore una ruta de entrada segura (norte-sur) puede proporcionar la protección necesaria frente a posibles ataques. No, no hemos visto a nadie intentarlo. Todavía. Pero ya hemos visto demasiadas brechas de seguridad provocadas por cabeceras HTTP, así que más vale prevenir que curar.

HTTP está ganando protagonismo, no solo como protocolo principal para aplicaciones, servicios y dispositivos, sino también para la telemetría, el seguimiento y el transporte de comandos operativos. Es un momento apasionante, pero debemos moderar ese «podemos hacer cualquier cosa» con un «pero hagámoslo de forma segura» si queremos evitar desastres operativos.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie