HTTPライジング: コンテナ環境におけるテレメトリ、追跡、テロ
HTTP はどこにでもあります。 あなたのテレビは HTTP を話します。 あなたの携帯電話。 あなたのタブレット。 あなたの車。 ネットワーク機能を備えたデバイスであれば、おそらく母国語と同じくらい流暢に HTTP を話します。
HTTP は柔軟性のあるものです。 ネットワーク上の他の TCP や IP とは異なり、HTTP はポイント A からポイント B に伝送できる情報量がほぼ無制限です。IP と TCP は、使用できる値をビット単位で定義する非常に厳格で柔軟性のない標準に準拠する必要がありますが、HTTP は伝送するデータに対して自由放任主義的なアプローチを採用しています。 文章。 バイナリ。 .JSON。 。 暗号化されています。 プレーンテキスト。
honey-badger と同様に、HTTP は気にしません。 すべてを運ぶことができます – そしてそれ以上のことも。
HTTP が常にその柔軟性を発揮している方法の 1 つは、ユーザーにはあまり見られないヘッダーです。 これは、すべての HTTP リクエストと応答によって運ばれるメタデータです。 コンテンツの種類からコンテンツの長さ、認証トークン、あなたが誰でどこにいたかを伝えるパンくずリストまで、あなたが望むと望まざるとにかかわらず、あらゆる情報が共有されます。
これは注目すべき重要な点です。なぜなら、コンテナ空間で見てきたように、HTTP ヘッダーは、クライアントとサービス間でデータを転送するメカニズムとしてだけでなく、これらの急速に変化する環境を非常に効率的に拡張するメタデータを共有する手段としても成長しているからです。
ますます注目されているのは、サービス メッシュの概念と、それに伴う運用情報を伝達するカスタム HTTP ヘッダーの追加です。 2 大オープンソース サービス メッシュ実装の 1 つを運営するBuoyant のブログでは、単一の HTTP 要求と応答のペアを構成するサービス間の非常に複雑なトランザクション セットを簡素化するのに役立つトレースの相関関係を有効にするのに必要なテレメトリの共有に HTTP ヘッダーがどのように依存しているかが説明されています。
前述のブログ全体を読むことに興味がない人のために、最も関連のある部分を以下に示します。強調表示は私が行っています。
Buoyant では、linkerd が提供する追加のトレース データのすべてを「マイクロサービス向けの魔法のテレメトリの散りばめ」と表現していますが、実際にはトレースを結び付けるために少量のリクエスト コンテキストが必要です。 そのリクエスト コンテキストは、linkerd がリクエストを受信したときに確立され、HTTP リクエストの場合は、linkerd がリクエストをアプリケーションにプロキシするときに HTTP ヘッダーを介して渡されます。 アプリケーションがリクエスト コンテキストを保持するには、送信するすべてのリクエストに、すべての受信l5d-ctx-* HTTP ヘッダーを変更せずに含めておく必要があります。
参照されているカスタム HTTP ヘッダーは、これらの高度に分散されたシステムでテレメトリを共有するために使用されるいくつかのヘッダーのうちの 1 つにすぎないことに注意してください。 ブログに記載されているように、 l5d-sampleヘッダーを使用してトレースのサンプル レートを調整できます。 したがって、これは情報を共有するためだけでなく、システムの運用制御を提供するためにも使用されます。
ちょっとそのことをよく考えてみましょう。 HTTP ヘッダーは、運用システムの動作を制御するために使用されます。 これを覚えておいてください。数段落後に重要になります。
この例では、制御プレーンをデータ プレーンから分離するのではなく、両方のプレーンが同時に転送され、いわばエンドポイントで形式と機能を分離することになります。 この特定のソリューションは、サービス メッシュの概念 (サービスからのすべての受信および送信要求がプロキシを通過する) に依存しているため、これは簡単に実現できます。 プロキシは、操作上の HTTP ヘッダーをフィルタリングし、リクエスト (または応答) を目的の受信者に転送する前に、それらに基づいて操作を行うことができます。 また、操作指示を追加したり、後でトレースを一致させるためにテレメトリを挿入したりすることもできます。
アプリケーション ネットワーキングも、コンテナ環境では一般的になりつつあります。 これは常に存在していましたが (少なくとも、プログラム可能なプロキシの世界にいる私たちにとっては)、柔軟性に対するニーズが高まるにつれて、現在では頻度が高まっています。 Ingress コントローラは、本質的には、IP アドレスや FQDN だけでなく、HTTP ヘッダーによって最も一般的に伝送されるアプリケーション固有のデータに基づいたルーティングを可能にするプログラム可能なプロキシです。 バージョン管理、ステアリング、スケーリング。 イングレス コントローラーのこれらすべての機能は、HTTP と、HTTP ヘッダーに対する無関心な態度によって可能になります。
残念なことに、HTTP ヘッダー自体も攻撃ベクトルとなります。 したがって、運用データを共有するだけでなく、運用動作を制御するために HTTP ヘッダーに依存することの影響を慎重に検討することが私たちの義務です。 HTTP ヘッダーはワイルドカード (実際、BNF を読んでください) であり、本質的には普遍的にテキストベースです。 これにより、変更が容易になるだけでなく、不正なコマンドを運ぶように操作することも容易になります。この悪意のあるコマンドは、増加する中間およびエンドポイントのデバイスやシステムによって使用されます。
もしそれがあなたを怖がらせないなら、あなたは注意を払っていなかったのです。
幸いなことに、コントロール プレーンとデータ プレーンの両方の方法として HTTP ヘッダーを使用することは、主にコンテナー化されたシステムに限定されています。 つまり、それらは一般に、組織がそれらの過剰な寛大さの脅威を軽減する能力を与える、公開されているいくつかの制御ポイントの背後に隠されています。 安全なインバウンド パス (南北) を組み合わせたアーキテクチャ アプローチにより、悪用に対する必要な保護を提供できます。 いいえ、誰もそれを試したのを見たことはありません。 まだ。 しかし、HTTP ヘッダーのせいですでに多くの侵害が発生しているため、後悔するよりは安全を第一に考えるべきです。
HTTP は、アプリ、サービス、デバイスの主要なプロトコルとしてだけでなく、テレメトリ、追跡、操作コマンドの転送にも使用されるようになっています。 今はエキサイティングな時期ですが、運用上の災害を避けるためには、「何でもできる」という考えを「安全に実行しよう」という考えに置き換える必要があります。