DevOps エンジニアとして、複数の異なるチームが開発した複数の Kubernetes アプリケーションをサポートする上で、レイヤ7のアプリケーションルーティングや HTTP 標準の適用を簡単に設定できる Ingress コントローラーを持つことは非常に重要です。LoadMaster では、Kubernetes サービスの公開におけるアプリケーショントラフィックの入り口管理とセキュリティの課題に、スムーズに対応できます。Kubernetes の Ingress コントローラーの API を介した統合によって、ワークフローとエンドユーザーのアプリケーションエクスペリエンス (AX) が大きく改善されました。
このブログでは、私たちのチームが、Kemp LoadMaster ロードバランシングソリューションを活用して、外部のお客様や社内チーム向けにどのようにサービスを提供しているかをご紹介します。今回は、中核となるコンテンツルールエンジンに焦点を当てますが、LoadMaster は包括的なソリューションであり、そのほかの機能も多く含まれています（付録に代表的なものを示します）。
私が所属するチームは、2017年から Microsoft Azure Kubernetes 環境でアプリケーションを公開しており、複数の Ingress コントローラーや構成モデルを試してきました。2019年初頭からは、社内利用を通じて LoadMaster を積極的に活用しており、いわゆる「自分たちで使ってみる」アプローチを取っています。このアプローチは直面する課題に直接対応することができ、大きな成果を上げています。
アプリケーションの高可用性を確保し、トラフィックの分散をコントロールするためによく行われる手法として仮想サービスの利用があります。仮想サービスは、1台または複数の実サーバーを抽象化したものとして機能します。具体的には、クラウド環境に仮想 LoadMaster をデプロイし、仮想サービスを設定しました。この仮想サービスは、Kubernetes ノード上の公開されたサービスに対して、設定された公開ポート (LoadMasterの用語では「リアルサーバーのソケット」) にトラフィックをルーティングします。
LoadMaster では、仮想サービス (Virtual Service) の概念がさらに拡張されており、1つの仮想サービスに対してサブ仮想サービス (Sub-Virtual Services) を持たせることができます。これは、複数のサービス/サイト/アプリケーション/マイクロサービスを1つの IP アドレスで公開したい場合や、サービスのサブコンポーネントの設定をサブコンポーネントごとに異なるものにしたい場合に特に有用です。(つまり、マイクロサービスアーキテクチャ)
LoadMaster では、正規表現構文に基づいたコンテンツルールを使用することで、トラフィックのコントロールや内容の変更が簡単に行えます。コンテンツルールエンジンでは、ヘッダーの追加/削除/編集、URL の書き換え、HTTP 本文の書き換え、ヘッダーや URI に基づくコンテンツマッチングなどが可能です。コンテンツマッチングルールは、リクエストの特性に基づいて、サブ仮想サービスや「リアルサーバー」に対して適用できます。ここでは、機能セットの一部を説明しているだけなので、コンテンツルールエンジンの詳細については、機能ドキュメントをご参照ください。
私たちの環境では、主に HTTP ホストヘッダーに対してコンテンツマッチングを行っています。FQDN (完全修飾ドメイン名) のサブドメイン部分に基づいて、公開するサービスやマイクロサービスを区別しています。もう１つのユースケースとしては、L3のパケットヘッダー内にあるソース IP アドレス (src-ip) をマッチング条件とし、特定の IP アドレスのみが特定のサービス/マイクロサービスにアクセスできるように制御しています。
私が所属するチームでは、2つの大規模な Kubernetes アプリケーションと、いくつかの小規模なアプリケーションを運用しており、LoadMaster 本番環境の管理を行っています。サブ仮想サービス付きの仮想サービスを使って、それぞれのアプリケーションやマイクロサービスを表わし、コンテンツマッチングと組み合わせることで、Kubernetes で公開されたソケットへのルーティングを容易に構成することができます。
例 (実際の環境に基づく)
上記の例では、トップレベルの仮想サービスが3つあります。うち2つはレガシーアプリケーションのサポート用 (仮想マシンをバックエンドに使用)、3つ目は Kubernetes 上で公開されているアプリケーション用です。
上記は、このアプリケーションに適した一般的なホスト名ベースのコンテンツマッチングルールを示しています。
これは、他のルールと連動または独立して、特定のサービス/マイクロサービスへのアクセスを制限/許可できるようにするソース IP アドレスによるマッチングの設定方法を示しています。例えば、アプリケーションの管理セクションへのアクセスを単一の特定ソース IP アドレスのみに制限する、といった設定が可能です。
コンテンツスイッチングのオプションは、設定の [Advanced Properties] セクションで有効にする必要があり、ルールは下部でそれぞれ関連するサブ仮想サービス (SubVS) に対して適用する必要があります。ルールの優先順位 (受信トラフィックに対してルールが処理される順序) を調整する必要がある場合もあります。
仮想サービスの設定だけでは、リアルサーバーが定義されていない限り、どこにもルーティングされません。最後のステップは、公開された Kubernetes ノードサービスのポートをサブ仮想サービスに追加することです。
ホスト名コンテンツスイッチングの設定の詳細については、このドキュメントを参照してください。また、ソース IP アドレスコンテンツスイッチの設定の詳細については、このドキュメントを参照してください。
LoadMaster には、Kubernetes サービスポッドと仮想サービスを自動的かつ動的にリンクさせるための API モジュールがあります。このロードバランサーは、Kubernetes の API サーバーと証明書ベースの認証を用いて通信するように設定されています。仮想サービスを作成したサービスにはタグが付与され、ポッドの作成や削除に伴って自動的にリンク/解除されるため、サービスの保守が完全に自動化されます (ゼロタッチメンテナンス)。
コンテンツルールを活用してアプリケーション層のセキュリティを強化できるので、開発体制が非常に小規模なアプリケーションやセキュリティにあまり深く踏み込んでいないアプリケーションを公開する際には特に、コンテンツルールの活用が有用だと私たちのチームは感じています。
これまでに当社のサイトは複数回のセキュリティ監査やペネトレーションテストを受けてきました。ここでは、当社がアプリケーションに対して実施してきた、代表的なセキュリティヘッダーの挿入や修正についてご紹介します。HTTP セキュリティヘッダーについては、あらゆるポリシーを適用することが可能です。無償で利用できる優れた監査ツールは多数存在しますが、HTTP セキュリティに関しては Mozilla Observatory を特に推奨します。
HTTP Strict-Transport-Security (HSTS) レスポンスヘッダーは、ブラウザやアプリケーションに対して、このサイトには HTTPS 経由でのみアクセスすべきだということを通知します。これは、サーバーの設定ミスやクライアントアプリ/ブラウザ側の問題によって、HTTP 経由でサイトにアクセスされるのを防止します (例えば、誰かが開発用インスタンスをうっかり本番環境に公開してしまったような場合にも……)。
このヘッダーの挿入ルールは、クライアントや中間デバイスに対して、Content-Type ヘッダーを変更せず、その指定に従うように指示します。これは、クライアント側のアプリやブラウザに対して、ペイロードデータを特定の方法で処理させ、予期せぬ挙動を回避する手段として有効です。
このヘッダーの挿入は、クロスサイトスクリプティング (XSS) 攻撃が検出された際に、ブラウザがページの読み込みを停止するよう指示するものです。現在では、この機能は多くの最新ブラウザでは非推奨となっており、代わりに Content-Security-Policy ヘッダーの使用が推奨されていますが、レガシーシステムのサポートという観点では、今なお有効な場面があります。
Content-Security-Policy (CSP) は、主に XSS 関連の攻撃を含む、様々な攻撃手法に対して防御するために使用される、現在の標準的な対策手段です。私たちの環境では、ロードバランサー上で CSP を有効化したところ、アプリケーション内部のワークフローに関するいくつかのセキュリティ上の懸念点が明らかになりました。当初、開発者たちはあまり快く思っていませんでしたが、最終的には意味のあるプロセス改善につながりました。CSP の詳細については、こちらまたはこちらを参照してください。
当社の社内開発環境では、Kubernetes 環境における高度なアプリケーションスイッチングの活用が大きく貢献しています。Kubernetes Ingress コントローラーの API と、使いやすく堅牢なコンテンツポリシールールセットを統合することで、ワークフローがよりスムーズかつセキュアになりました。LoadMaster ソリューションは、私たち自身の開発チームはもちろん、多くのお客様の課題を解決してきました。このレポートが、皆様の DevOps 環境にとって少しでも参考になれば幸いです。