HTTP en hausse : Télémétrie, suivi et terreur dans les environnements de conteneurs

HTTP est omniprésent. Votre télévision parle HTTP. Ton téléphone. Votre tablette. Ta voiture. S’il s’agit d’un appareil doté d’un réseau, il parle probablement HTTP aussi couramment que vous parlez votre langue maternelle.

HTTP est une chose flexible. Contrairement à ses voisins réseau, TCP et IP, il est presque illimité dans les informations qu'il peut transporter du point A au point B. Alors que IP et TCP sont tenus d'adhérer à des normes très strictes et inflexibles qui définissent, au bit près, les valeurs qui peuvent être utilisées, HTTP adopte une approche de laisser-faire vis-à-vis des données qu'il transporte. Texte. Binaire. JSON. XML. Crypté. Texte brut.

Comme le blaireau-miel, HTTP s'en fiche. Il transportera tout – et plus encore.

L’une des façons dont HTTP fait constamment preuve de flexibilité réside dans ses en-têtes rarement vus par les utilisateurs. Il s'agit des métadonnées transportées par chaque requête et réponse HTTP. Il partage tout, du type de contenu à la longueur du contenu, en passant par les jetons d'autorisation et les miettes de pain qui racontent qui vous êtes et où vous êtes allé, que vous le vouliez ou non.

Il est important de noter cela car, comme nous l’avons vu dans le domaine des conteneurs, les en-têtes HTTP se développent en tant que mécanisme non seulement pour transporter des données entre les clients et les services, mais également comme moyen de partager les métadonnées qui permettent à ces environnements en évolution rapide de s’adapter de manière très efficace.

La notion de service-mesh et, avec elle, l’ajout d’en-têtes HTTP personnalisés qui transportent des informations opérationnelles sont de plus en plus prisés. Ce blog de Buoyant , la société à l'origine de l'une des deux principales implémentations de maillage de services open source, illustre la dépendance aux en-têtes HTTP pour le partage de la télémétrie nécessaire pour permettre la corrélation des traces qui aident à simplifier l'ensemble très complexe de transactions entre les services qui constituent une seule paire de requêtes et de réponses HTTP.

Pour ceux qui ne sont pas intéressés par la lecture de l’intégralité du blog susmentionné, voici le passage le plus pertinent – c’est moi qui le souligne :

Bien que chez Buoyant, nous aimions décrire toutes les données de traçage supplémentaires fournies par Linkerd comme des « poudres de télémétrie magiques pour les microservices », la réalité est que nous avons besoin d'une petite quantité de contexte de requête pour relier les traces ensemble. Ce contexte de requête est établi lorsque Linkerd reçoit une requête et, pour les requêtes HTTP, il est transmis via les en-têtes HTTP lorsque Linkerd transmet la requête à votre application. Pour que votre application préserve le contexte de la requête, elle doit inclure, sans modification, tous les en-têtes HTTP l5d-ctx-* entrants sur toutes les requêtes sortantes qu'elle effectue.

Il convient de noter que les en-têtes HTTP personnalisés référencés ne sont que l’un des nombreux éléments utilisés pour partager la télémétrie dans ces systèmes hautement distribués. Comme indiqué dans le blog, l’en-tête l5d-sample peut être utilisé pour ajuster les taux d’échantillonnage de traçage. Il n’est donc pas seulement utilisé pour partager des informations, mais également pour assurer le contrôle opérationnel du système .

Laissez cela pénétrer votre esprit un instant. Les en-têtes HTTP sont utilisés pour contrôler le comportement des systèmes opérationnels. N’oubliez pas ceci, cela sera important dans quelques paragraphes.

Plutôt que de séparer le plan de contrôle du plan de données, dans ce cas, les deux plans sont transportés simultanément et il incombe aux points de terminaison de séparer la forme de la fonction, pour ainsi dire. Étant donné que cette solution particulière repose sur un concept de service-mesh (dans lequel chaque requête entrante et sortante d’un service passe par un proxy), cela est assez facile à réaliser. Le proxy peut filtrer les en-têtes HTTP opérationnels et agir sur eux avant de transmettre la demande (ou la réponse) à son destinataire prévu. Il peut également ajouter des instructions opérationnelles ainsi qu'insérer de la télémétrie pour aider à faire correspondre les traces ultérieurement.

La mise en réseau des applications devient également une chose courante dans les environnements de conteneurs. Bien que cela ait toujours existé (du moins pour ceux d’entre nous dans le monde des proxys programmables), cela augmente désormais avec une fréquence plus élevée à mesure que le besoin d’une plus grande flexibilité augmente. Les contrôleurs d’entrée sont, à la base, des proxys programmables qui permettent un routage basé non seulement sur des adresses IP ou des noms de domaine complets, mais également sur des données spécifiques à l’application, le plus souvent véhiculées par les en-têtes HTTP. Versionnage, pilotage, mise à l'échelle. Toutes ces fonctions d’un contrôleur d’entrée sont rendues possibles par HTTP et son attitude indifférente envers les en-têtes HTTP.

Malheureusement, les en-têtes HTTP constituent également leur propre vecteur d’attaque. Il nous incombe donc d’examiner attentivement les ramifications du recours aux en-têtes HTTP non seulement pour partager des données opérationnelles mais également pour contrôler le comportement opérationnel. Les en-têtes HTTP sont des caractères génériques (sérieusement, lisez le BNF) qui sont universellement basés sur du texte par nature. Cela les rend non seulement faciles à modifier, mais également à manipuler pour véhiculer des commandes malveillantes qui sont consommées par un nombre croissant d'appareils et de systèmes intermédiaires et terminaux.

Si cela ne vous effraie pas, c’est que vous n’avez pas fait attention.

Heureusement, l’utilisation des en-têtes HTTP comme méthode de contrôle et de plan de données est principalement limitée aux systèmes conteneurisés. Cela signifie qu’ils sont généralement cachés derrière plusieurs points de contrôle accessibles au public qui permettent aux organisations d’atténuer la menace de leur nature trop généreuse. Une approche architecturale combinant un chemin d’entrée sécurisé (nord-sud) peut fournir la protection nécessaire contre l’exploitation. Non, nous n’avons vu personne essayer cela. Encore. Mais nous avons déjà vu trop de violations dues aux en-têtes HTTP, il vaut donc mieux prévenir que guérir.

HTTP est en passe de devenir le protocole principal pour les applications, les services et les appareils, mais également pour la télémétrie, le suivi et le transport des commandes opérationnelles. C’est une période passionnante, mais nous devons tempérer le « nous pouvons tout faire » par le « mais faisons-le en toute sécurité » si nous voulons éviter les catastrophes opérationnelles.