HTTP Rising: Telemetrie, Tracking und Terror in Container-Umgebungen

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

HTTP ist allgegenwärtig. Ihr Fernseher spricht HTTP. Ihr Smartphone. Ihr Tablet. Ihr Auto. Wenn ein Gerät netzwerkfähig ist, spricht es HTTP wahrscheinlich so fließend wie Sie Ihre Muttersprache.

HTTP ist äußerst flexibel. Anders als seine Nachbarn im Netzwerk – TCP und IP – sind den Informationen, die es von Punkt A nach Punkt B übertragen kann, nahezu keine Grenzen gesetzt. Während IP und TCP sehr strenge, unflexible Standards einhalten müssen, die bis aufs Bit genau festlegen, welche Werte verwendet werden dürfen, verfolgt HTTP bei den übertragenen Daten einen Laissez-faire-Ansatz. Text. Binärdaten. JSON. XML. Verschlüsselt. Klartext.

Wie der Honigdachs kümmert sich HTTP um nichts. Es transportiert einfach alles – und noch mehr.

Eine der Arten, wie HTTP ständig seine, nun ja, Flexibilität unter Beweis stellt, sind seine für Benutzer nur selten sichtbaren Header. Dabei handelt es sich um die Metadaten, die mit jeder HTTP-Anfrage und -Antwort übertragen werden. Sie geben alles preis – vom Inhaltstyp über die Inhaltslänge und Autorisierungs-Token bis hin zu digitalen Brotkrumen, die verraten, wer Sie sind und wo Sie gewesen sind – ob Sie wollen oder nicht.

Dies ist wichtig zu erwähnen, denn wie wir im Container-Umfeld gesehen haben, dienen HTTP-Header zunehmend nicht nur als Mechanismus für den Datentransport zwischen Clients und Diensten, sondern auch für den Austausch von Metadaten, die eine so effiziente Skalierung dieser hochdynamischen Umgebungen ermöglichen.

Zunehmend an Bedeutung gewinnt das Konzept eines Service Mesh und damit die Ergänzung um benutzerdefinierte HTTP-Header, die Betriebsinformationen enthalten. Dieser Blogbeitrag von Buoyant – dem Unternehmen hinter einer der beiden führenden Open-Source-Implementierungen von Service Mesh – verdeutlicht, wie sehr man beim Austausch von Telemetriedaten auf HTTP-Header angewiesen ist. Diese Daten ermöglichen die Korrelation von Traces und tragen so dazu bei, die hochkomplexen dienstübergreifenden Transaktionsabläufe, aus denen ein einzelnes HTTP-Anfrage-Antwort-Paar besteht, leichter nachvollziehbar zu machen.

Für alle, die nicht den gesamten oben erwähnten Blogbeitrag lesen möchten, folgt hier der relevanteste Abschnitt – die Hervorhebung stammt von mir:

Wir bei Buoyant bezeichnen all die zusätzlichen Tracing-Daten, die linkerd bereitstellt, zwar gerne als „magische Telemetrie-Streusel für Microservices“, doch tatsächlich benötigen wir ein wenig Anfragekontext, um die Traces miteinander zu verknüpfen. Dieser Anfragekontext wird erstellt, wenn linkerd eine Anfrage empfängt, und bei HTTP-Anfragen über HTTP-Header weitergegeben, wenn linkerd die Anfrage an Ihre Anwendung weiterleitet. Damit Ihre Anwendung den Anfragekontext beibehält, muss sie bei allen ausgehenden Anfragen sämtliche eingehenden l5d-ctx-*-HTTP-Header unverändert übernehmen.

Es ist zu beachten, dass die erwähnten benutzerdefinierten HTTP-Header nur einige von mehreren sind, die zur gemeinsamen Nutzung von Telemetriedaten in diesen hochgradig verteilten Systemen verwendet werden. Wie im Blog erwähnt, kann der Header l5d-sample verwendet werden, um die Abtastraten für das Tracing anzupassen. Er dient also nicht nur dem Austausch von Informationen, sondern auch dazu, die operative Kontrolle über das System zu ermöglichen.

Lassen Sie das einen Moment auf sich wirken. HTTP-Header werden dazu verwendet, das Verhalten operativer Systeme zu steuern. Behalten Sie das im Hinterkopf, denn in einigen Absätzen wird es noch wichtig sein.

Anstatt die Steuerungsebene von der Datenebene zu trennen, werden in diesem Fall beide Ebenen gleichzeitig übertragen, und es ist Aufgabe der Endpunkte, gewissermaßen Form und Funktion voneinander zu trennen. Da diese spezielle Lösung auf einem Service-Mesh-Konzept beruht – bei dem jede ein- und ausgehende Anfrage eines Dienstes einen Proxy durchläuft –, lässt sich dies recht einfach bewerkstelligen. Der Proxy kann die für den Betrieb relevanten HTTP-Header herausfiltern und entsprechend darauf reagieren, bevor er die Anfrage (oder Antwort) an den vorgesehenen Empfänger weiterleitet. Außerdem kann er betriebliche Anweisungen hinzufügen und Telemetriedaten einfügen, um die Traces später einander zuordnen zu können.

Auch Application Networking wird in Container-Umgebungen immer üblicher. Zwar gibt es das schon seit jeher (zumindest für diejenigen unter uns, die sich mit programmierbaren Proxys beschäftigen), doch mit dem wachsenden Bedarf an mehr Flexibilität kommt es zunehmend häufiger zum Einsatz. Ingress-Controller sind im Kern programmierbare Proxys, die das Routing nicht nur anhand von IP-Adressen oder FQDNs ermöglichen, sondern auch anhand anwendungsspezifischer Daten, die meist in HTTP-Headern übertragen werden. Versionierung, Verkehrssteuerung, Skalierung: All diese Funktionen eines Ingress-Controllers werden durch HTTP und dessen gleichgültigen Umgang mit HTTP-Headern ermöglicht.

Leider stellen HTTP-Header auch einen eigenen Angriffsvektor dar. Daher müssen wir die Auswirkungen sorgfältig abwägen, wenn wir uns auf HTTP-Header verlassen, um nicht nur Betriebsdaten auszutauschen, sondern auch das Betriebsverhalten zu steuern. HTTP-Header sind ein Joker (im Ernst, lesen Sie die BNF) und grundsätzlich textbasiert. Dadurch lassen sie sich nicht nur leicht verändern, sondern auch so manipulieren, dass sie schädliche Befehle übertragen, die von einer wachsenden Zahl zwischengeschalteter Geräte und Systeme sowie Endgeräte und Endsysteme verarbeitet werden.

Wenn Ihnen das keine Angst macht, haben Sie nicht aufgepasst.

Glücklicherweise ist die Nutzung von HTTP-Headern sowohl für die Steuerungs- als auch für die Datenebene hauptsächlich auf containerisierte Systeme beschränkt. Das bedeutet, dass sie sich in der Regel hinter mehreren öffentlich zugänglichen Kontrollpunkten verbergen, die es Unternehmen ermöglichen, die von ihrer allzu großzügigen Auslegung ausgehende Bedrohung einzudämmen. Ein Architekturansatz mit einem sicheren eingehenden Pfad (Nord-Süd) kann den notwendigen Schutz vor einer Ausnutzung bieten. Nein, wir haben noch niemanden gesehen, der das versucht hat. Noch nicht. Aber wir haben bereits zu viele Sicherheitsverletzungen erlebt, die auf HTTP-Header zurückzuführen waren. Daher gilt: Vorsicht ist besser als Nachsicht.

HTTP entwickelt sich nicht nur zum wichtigsten Protokoll für Anwendungen, Dienste und Geräte, sondern auch für Telemetrie, Nachverfolgung und die Übertragung von Betriebsbefehlen. Es ist eine spannende Zeit, doch wir müssen die Haltung „Wir können alles machen“ um den Grundsatz „Aber lasst es uns sicher machen“ ergänzen, wenn wir betriebliche Katastrophen vermeiden wollen.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie