Fastly 次世代 WAF を Kubernetes にデプロイする7つの方法
かつてスポーツチームの監督は、紙の作戦ノートを使ってチームと戦略を練っていました。最近では、重要なプレーや選手のパフォーマンスに関する情報を素早く柔軟にチェックできるタブレットなど、最新テクノロジーを活用する監督が増えています。同様に、DevOps チームもアプリケーションコンテナや、Kubernetes のようなコンテナ・オーケストレーション・システムなどの新しいツールやフレームワークを採用し、より迅速かつ効率的にアプリケーションを構築してリリースしています。
Docker のようなコンテナは、アプリケーションとそれをあらゆる環境で安定して動作させるのに必要なすべてをパッケージ化するため、開発者はより迅速にコードをリリースすることができます。コンテナの使用が普及する中、コンテナ化されたアプリケーションを大規模にデプロイして管理する手段として Kubernetes の人気が高まっています。CNCF が2021年に調査を実施し、2022年に発表した Cloud Native Survey Report では、以下のように報告されています。
記録的な96%もの組織が Kubernetes を使用、または検討して おり、2019年の78%、2020年の83%から大きく飛躍
93%の組織がプロダクションでコンテナを使用、または検討しており、昨年の調査時の92%から若干増加
現時点で560万人以上の開発者が Kubernetes を使用していると推定
Fastly は、Kubernetes を利用しているお客様に柔軟性の高いインストールオプションを提供する必要性を実感しました。以前のブログ記事では、Fastly 次世代 WAF (Powered by Signal Sciences) と Kubernetes を使って Web アプリケーションのレイヤー7のセキュリティをオートスケールする7つの方法のひとつを取り上げました。今回は、Fastly 次世代 WAF を Kubernetes と一緒にインストールする7つの方法すべてについて簡単にご紹介します。
まず最初に、Fastly 次世代 WAF のソフトウェアコンポーネントについて簡単にご説明します。Fastly の WAF では、エージェントとモジュールの間に特許取得済みの独自の通信技術を使用しています。これらのエージェントとモジュールはお客様のインフラストラクチャ上で動作し、帯域外で Fastly の Cloud Engine と通信し、強化された最新のインテリジェンスを受信します。このモジュールは、Fastly 次世代 WAF をリバースプロキシモードで動作させる場合は必要ありません。これについては、後ほどご説明します。
デプロイオプションは3x4のマトリクスで構成されています。すなわち、Fastly 次世代 WAF を Kubernetes にインストール可能な3つの「レイヤー」と、4つのデプロイ「メソッド」があります。
レイヤー
スタックの上位レイヤーからアプリケーションレイヤーまで、各レイヤーについてご紹介し、組織がソフトウェアのデプロイを管理する方法に基づいて、どのレイヤーを選ぶべきかその理由についてご説明します。
上位レイヤーには、Kubernetes のイングレスコントローラーがあります。このオプションは、イングレスコントローラーを使用していて、イングレスコントローラーの下に置かれたすべてのアプリのセキュリティを一元化したいと考えている組織に適しています。
次は、中間層またはサービスレイヤーと呼ばれるものです。このオプションは、イングレスコントローラーを使用していない、またはトラフィックのルーティングに別のロードバランサーを使用していながら、(Fastly 次世代 WAF のインストールが可能にもかかわらず) 何らかの理由でそこにインストールしたなくない組織に向いています。
最後にアプリケーションレイヤーは、アプリケーションチームが自分たちでインストールをコントロールしたい場合に最適です。
メソッド
これらの各レイヤーで、Kubernetes と併せて Fastly 次世代 WAF を以下の方法でデプロイできます。
モジュールとエージェントを同じコンテナ内で実行する。
モジュールとエージェントを別のサイドカーコンテナ内で実行する。
同じアプリケーションコンテナ内でリバースプロキシモードでエージェントを実行する。
アプリケーションコンテナのサイドカー内でリバースプロキシモードでエージェントを実行する。
3つのレイヤーと4つのデプロイ方法を組み合わせ、12種類のインストール方法が可能なことを考えると、コンテナと Kubernetes の利用に優れた柔軟性があることは明白です。Fastly 次世代 WAF は12種類すべてのインストール方法をサポートしますが、ここでは以下の表の星が付いているメソッドの例をご紹介します。
_
| インストール方法 : | レイヤー1 : イングレスコントローラー | レイヤー2 : ミッドティアサービス | レイヤー3 : アプリ層 |
|---|---|---|---|
1. エージェント + モジュール (同一アプリコンテナ内) | ✓* | ✓ | ✓* |
2. エージェント + モジュール (それぞれ異なるコンテナ内) | ✓* | ✓ | ✓* |
3. リバースプロキシモードのエージェント (アプリと同一コンテナ内) | ✓ | ✓ | ✓* |
4. リバースプロキシモードのエージェント (サイドカーコンテナ内) | ✓ | ✓* | ✓* |
* 実装メソッドの例については以下をご覧ください。
メソッド1 : ポッドコンテナ – エージェントとモジュール
同じ Kubernetes のポッドコンテナ内にエージェントとモジュールをデプロイします。エージェントとモジュールはアプリケーションと一列に並びます。
メソッド2 : マルチコンテナ – エージェントとモジュール
この方法では、モジュールとエージェントが分けられます。モジュールをアプリと一緒に単一のコンテナにデプロイし、エージェントを別のコンテナにデプロイします。モジュールとエージェントはそれぞれ別のコンテナ内にありますが、両方とも同じ Kubernetes ポッド内にあります。エージェントとモジュールのコンテナはボリュームを共有し、ドメインソケット経由で通信します。
メソッド3 : ポッドコンテナ – リーバスプロキシモードのエージェント
Fastly 次世代 WAF のエージェントがプロキシモードで実行されている場合、エージェントをアプリケーションと同じポッドコンテナ内にデプロイできます。メソッド1と同様に Fastly 次世代 WAF はアプリケーションと一列に並び、モジュールの設定のみが異なります。
メソッド4 : ポッドマルチコンテナ - サイドカーコンテナにリバースプロキシモードのエージェント
メソッド2と同様に、エージェントをモジュールなしでリバースプロキシモードでデプロイします。異なるのは、エージェントがアプリケーションとは別のコンテナに配置される点です。リクエストはアプリケーションコンテナに届く前にエージェントコンテナを通過します。エージェントとアプリケーションコンテナは同じポッド内に配置されます。
レイヤー1と2の方法では、イングレスサービスが使用されます。イングレスサービスの背後にある各アプリケーションに対して個別にルールの調整を行う必要がある従来型の WAF と異なり、独自の SmartParse メソッドによる動的検出機能を備えた Fastly の次世代 WAF では、そのようなオーバーヘッドは一切不要です。
レイヤー1 x メソッド1 : イングレスポッドコンテナ – NGINX または HAProxy
この方法では、NGINX や HAProxy と同じコンテナにモジュールとエージェントをデプロイできます。モジュールは NGINX または HAProxy 上に配置され、エージェントも同じコンテナ内に配置されます。リクエストはすべてイングレスポッドを通過し、必要に応じてオートスケールします。
レイヤー1 x メソッド2 : イングレスポッドマルチコンテナ – NGINX または HAProxy
前の方法と似ていますが、唯一異なるのはモジュールとエージェントが同じイングレスポッド内でそれぞれ別のコンテナにデプロイされる点です。メソッド2と同様に、エージェントとモジュールはドメインソケットのボリュームを共有する必要があります。このデプロイ方法では、Kubernetes クラスターをオープンインターネットへの露出から保護します。
レイヤー2 x メソッド4 : マルチサービス – リバースプロキシモードのエージェント
このデプロイ方法では、アプリケーションとは異なるポッドでエージェントをリバースプロキシモードで実行します。エージェントポッドはリクエストを受信して検査し、ブロックまたはアプリケーションポッドにパスします。これにより、エージェ ントまたはアプリケーションを個別にオートスケールできます。
アプリケーションとマイクロサービスを保護する究極の柔軟性
Fastly 次世代 WAF なら、DevOps チームが Kubernetes でコンテナを使用する方法にかかわらず、アプリケーションとマイクロサービスを迅速に保護できる究極の柔軟性が得られます。ここでご紹介したインストール例では、インストール後すぐにアプリケーションの保護を開始し、Kubernetes を使ったアプリケーションのデプロイに変更があっても、アプリケーションを保護し続けることができます。
_
