HTTP steigt: Telemetrie, Tracking und Terror in Containerumgebungen

HTTP ist allgegenwärtig. Ihr Fernseher spricht HTTP. Ihr Telefon. Ihr Tablet. Dein Auto. Wenn es sich um ein Gerät mit Netzwerkfunktion handelt, spricht es HTTP wahrscheinlich so fließend, wie Sie Ihre Muttersprache sprechen.

HTTP ist eine flexible Sache. Im Gegensatz zu seinen Netzwerknachbarn TCP und IP sind die Informationen, die es von Punkt A nach Punkt B übertragen kann, nahezu unbegrenzt. Während IP und TCP sehr strenge, unflexible Standards einhalten müssen, die bitgenau festlegen, welche Werte verwendet werden können, verfolgt HTTP einen Laissez-faire-Ansatz hinsichtlich der übertragenen Daten. Text. Binär. JSON. XML. Verschlüsselt. Klartext.

Wie beim Honigdachs ist es HTTP egal. Es trägt alles – und noch mehr.

Eine Möglichkeit, mit der HTTP ständig seine Flexibilität beweist, sind seine Header, die von Benutzern selten gesehen werden. Dies sind die Metadaten, die von jeder HTTP-Anfrage und -Antwort übertragen werden. Es gibt alles weiter, vom Inhaltstyp und der Inhaltslänge bis hin zu Autorisierungstokens und Brotkrumen, die verraten, wer Sie sind und wo Sie waren – ob Sie es wollen oder nicht.

Dies ist wichtig zu beachten, da HTTP-Header, wie wir im Containerbereich gesehen haben, nicht nur als Mechanismus zum Transport von Daten zwischen Clients und Diensten zunehmend eingesetzt werden, sondern auch als Mittel zum Teilen der Metadaten, die für eine so effiziente Skalierung dieser schnelllebigen Umgebungen sorgen.

Das Konzept eines Service-Mesh und die damit verbundene Hinzufügung benutzerdefinierter HTTP-Header, die Betriebsinformationen enthalten, gewinnen zunehmend an Bedeutung. Dieser Blog von Buoyant – dem Unternehmen hinter einer der beiden führenden Open-Source-Service-Mesh-Implementierungen – veranschaulicht die Abhängigkeit von HTTP-Headern zum Teilen von Telemetriedaten, die für die Korrelation von Traces erforderlich sind, die zur Vereinfachung der hochkomplexen Transaktionen zwischen Diensten beitragen, die ein einzelnes HTTP-Anforderungs- und Antwortpaar bilden.

Für diejenigen, die nicht daran interessiert sind, den gesamten oben genannten Blog zu lesen, hier der relevanteste Teil – die Hervorhebung stammt von mir:

Während wir bei Buoyant die zusätzlichen Tracing-Daten, die linkerd bereitstellt, gerne als „magische Telemetrie-Streusel für Microservices“ bezeichnen, benötigen wir in Wirklichkeit eine kleine Menge an Anforderungskontext, um die Traces miteinander zu verknüpfen. Dieser Anforderungskontext wird erstellt, wenn Linkerd eine Anforderung empfängt, und bei HTTP-Anforderungen wird er über HTTP-Header übergeben, wenn Linkerd die Anforderung an Ihre Anwendung weiterleitet. Damit Ihre Anwendung den Anforderungskontext beibehält, muss sie alle eingehenden l5d-ctx-*- HTTP-Header ohne Änderungen in alle ausgehenden Anforderungen einschließen, die sie stellt.

Es ist zu beachten, dass die referenzierten benutzerdefinierten HTTP-Header nur einer von mehreren sind, die zum Teilen von Telemetriedaten in diesen stark verteilten Systemen verwendet werden. Wie im Blog erwähnt, kann der L5D-Sample -Header verwendet werden, um die Abtastraten beim Tracing anzupassen. Es wird also nicht nur zum Teilen von Informationen verwendet, sondern auch, um die operative Kontrolle über das System zu ermöglichen.

Lassen Sie das einen Moment auf sich wirken. HTTP-Header werden verwendet, um das Verhalten von Betriebssystemen zu steuern. Denken Sie daran, es wird in einigen Absätzen wichtig sein.

Anstatt die Steuerebene von der Datenebene zu trennen, werden in diesem Fall beide Ebenen gleichzeitig transportiert und es ist die Aufgabe der Endpunkte, sozusagen Form von Funktion zu trennen. Da diese spezielle Lösung auf einem Service-Mesh-Konzept basiert, bei dem jede eingehende und ausgehende Anfrage eines Dienstes über einen Proxy läuft, ist dies problemlos zu erreichen. Der Proxy kann die operativen HTTP-Header herausfiltern und auf sie reagieren, bevor er die Anfrage (oder Antwort) an den vorgesehenen Empfänger weiterleitet. Darüber hinaus können beliebige Betriebsanweisungen hinzugefügt und Telemetriedaten eingefügt werden, um das spätere Abgleichen der Spuren zu erleichtern.

Auch die Anwendungsvernetzung wird in Containerumgebungen immer üblicher. Obwohl dieses Problem schon immer bestand (zumindest für diejenigen von uns in der Welt der programmierbaren Proxys), kommt es jetzt immer häufiger vor, da der Bedarf an mehr Flexibilität wächst. Ingress-Controller sind im Kern programmierbare Proxys, die ein Routing nicht nur auf Grundlage von IP-Adressen oder FQDNs ermöglichen, sondern auch auf Grundlage anwendungsspezifischer Daten, die am häufigsten in HTTP-Headern enthalten sind. Versionierung, Steuerung, Skalierung. Alle diese Funktionen eines Ingress-Controllers werden durch HTTP und seine „Don’t-Care“-Einstellung gegenüber HTTP-Headern ermöglicht.

Leider sind HTTP-Header auch ihr eigener Angriffsvektor. Es ist daher unsere Pflicht, sorgfältig zu bedenken, welche Auswirkungen es hat, wenn wir uns nicht nur beim Austausch von Betriebsdaten, sondern auch bei der Steuerung des Betriebsverhaltens auf HTTP-Header verlassen. HTTP-Header sind Platzhalter (im Ernst, lesen Sie den BNF), die universell textbasiert sind. Dadurch lassen sie sich nicht nur leicht ändern, sondern auch so manipulieren, dass sie bösartige Befehle übermitteln, die von einer wachsenden Zahl von Zwischen- und Endpunktgeräten und -systemen verwendet werden.

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

Glücklicherweise ist die Verwendung von HTTP-Headern als Methode sowohl der Steuerungs- als auch der Datenebene in erster Linie auf containerisierte Systeme beschränkt. Dies bedeutet, dass sie im Allgemeinen hinter mehreren nach außen gerichteten Kontrollpunkten verborgen sind, die es den Organisationen ermöglichen, die Gefahr ihrer übermäßigen Großzügigkeit einzudämmen. Ein architektonischer Ansatz, der einen sicheren eingehenden Pfad (Nord-Süd) kombiniert, kann den notwendigen Schutz vor Ausnutzung bieten. Nein, wir haben noch niemanden gesehen, der das versucht hat. Noch. Aufgrund von HTTP-Headern sind uns jedoch bereits zu viele Sicherheitsverletzungen aufgefallen, sodass Vorsicht besser ist als Nachsicht.

HTTP wird nicht nur zum primären Protokoll für Apps, Dienste und Geräte, sondern auch für Telemetrie, Tracking und den Transport von Betriebsbefehlen. Es sind spannende Zeiten, aber wenn wir betriebliche Katastrophen vermeiden wollen, müssen wir die Aussage „Wir können alles tun“ durch „Aber lasst es uns auf sichere Weise tun“ mäßigen.