NGINX Ingress Controller による TCP/UDP ロード バランシングと WAF 構成の強化

標準の Kubernetes Ingress リソースは、基本的な Ingress ロード バランシングのプロビジョニングと構成には最適ですが、 Kubernetes を本番環境グレードにするために必要なカスタマイズ機能は含まれていません。 代わりに、NGINX 以外のユーザーは、エラーが発生しやすく、使いにくく、安全ではなく、きめ細かいスコープ設定ができないアノテーション、ConfigMap、カスタム テンプレートを使用することになります。 NGINX Ingress リソースは、この問題に対する答えです。

NGINX Ingress リソースは、NGINX オープンソース バージョンとNGINX Plus ベースのNGINX Ingress Controller の両方のバージョンで利用できます。 これらは、ネイティブでタイプセーフなインデントされた構成スタイルを提供し、Ingress ロード バランシングの実装を簡素化します。 このブログでは、NGINX Ingress Controller 1.11.0 で導入された、WAF と負荷分散ポリシーの構成を容易にする 2 つの機能に焦点を当てます。

• TransportServer リソース– TransportServer リソースは、TCP、UDP、および TLS パススルー負荷分散の構成を定義します。 TCP/UDP 負荷分散を強化するために、ヘルス チェック、ステータス レポート、構成スニペットを追加しました。
• NGINX Ingress WAF ポリシー– NGINX Ingress Controller を使用して NGINX App Protect 3.0 をデプロイすると、NGINX Ingress リソースを活用して特定の Kubernetes サービスに WAF ポリシーを適用できます。

TransportServer リソースの強化

NGINX Ingress Controller 1.11.0 は、次の領域でTransportServer (TS) リソースを拡張します。

• スニペット
• 健康診断
• 複数のTSリソースのサポート

注記： リリース 1.11.0 での TransportServer リソースへの追加は、現在開発中のテクノロジー プレビューです。 将来のリリースでは、安定した本番環境対応の品質基準に引き上げられる予定です。

TransportServer スニペット

NGINX Ingress Controllerでは、VirtualServer および VirtualServerRoute (VS および VSR) リソースの構成スニペットを導入しました。これにより、HTTP ベースのクライアントの NGINX Ingress 構成をネイティブに拡張できるようになります。 リリース 1.11.0 では TS リソースのスニペットが導入されているため、NGINX および NGINX Plus の全機能を簡単に活用して TCP/UDP ベースのサービスを提供できます。 たとえば、スニペットを使用して、IPアドレスと範囲を使用してサービスにアクセスできるクライアントを定義する拒否および許可ディレクティブを追加できます。

apiバージョン: k8s.nginx.org/v1alpha1kind: TransportServer
メタデータ:
名前: cafe
仕様:
ホスト: cafe.example.com
serverSnippets: |
192.168.1.1 を拒否します。
192.168.1.0/24 を許可します。
アップストリーム:
- 名前: tea
サービス: tea-svc
ポート: 80

健康診断

Kubernetes クラスターの健全性を監視するために、NGINX Ingress Controller は、アプリケーション ポッドに対してローカルなKubernetes プローブを考慮するだけでなく、TCP/UDP ベースのアップストリーム サービス間のネットワークの状態を監視し、実行中のトランザクションの健全性を評価するパッシブ ヘルス チェックと、合成接続要求を使用してエンドポイントを定期的にプローブするアクティブ ヘルス チェック (NGINX Plus 専用) も行います。

ヘルス チェックは、サーキット ブレーキングやアプリケーション エラーの処理に非常に役立ちます。 TS リソースのhealthCheckフィールドのパラメータを使用して、プローブ間の間隔、プローブのタイムアウト、プローブ間の遅延時間などを設定し、ヘルス チェックをカスタマイズできます。

さらに、NGINX Ingress Controller からヘルス プローブのアップストリーム サービスとポートの宛先を設定することもできます。 これは、アプリケーションの複数の下流コンポーネントを監視する別のプロセスまたはサブシステムによって、上流アプリケーションの健全性が別のリスナーに公開される状況で役立ちます。

ingressClassNameによる複数の TransportServer リソースのサポート

TS リソースを更新して適用する場合、構成が有効であり、対応する Ingress Controller デプロイメントに正常に適用されたことを確認すると役立ちます。 リリース 1.11.0 では、TS リソースのingressClassNameフィールドとステータス レポートが導入されています。 ingressClassNameフィールドは、複数のデプロイメントがある環境で、TS リソースが特定の Ingress Controller デプロイメントによって処理されることを保証します。

1 つまたはすべての TS リソースのステータスを表示するには、 kubectl get transportserverコマンドを実行します。出力には、状態 (有効または無効)、最新の更新の理由、および (単一の TS の場合) カスタム メッセージが含まれます。

$ kubectl get transportserver NAME STATE REASON AGE dns-tcp Valid AddedOrUpdated 47m $ kubectl describe transportserver dns-tcp . . .
状態：
  メッセージ：  default/dns-tcp の設定が追加または更新されました。理由:   追加または更新された状態:    有効

複数の TS リソースが同じホスト/リスナーを競合する場合、NGINX Ingress Controller は最も古いタイムスタンプを持つ TS リソースを選択し、その状況で確定的な結果を保証します。

ネイティブ NGINX App Protect サポートによる WAF ポリシーの定義

NGINX Ingress リソースを使用すると、構成がより簡単かつ柔軟になるだけでなく、トラフィック制御をさまざまなチームに委任したり、VirtualServerRoute (VSR) リソースで定義されているアプリケーション サブルートを所有するユーザーに厳格な権限制限を課したりすることもできます。 NGINX Ingress リソースは、適切なチームに適切な Kubernetes リソースへのアクセス権を与えることで、ネットワーク リソースをきめ細かく制御し、ユーザーが侵害されたりハッキングされたりした場合にアプリケーションに生じる潜在的な損害を軽減します。

リリース 1.11.0 では、ネイティブ Web アプリケーション ファイアウォール (WAF)ポリシーオブジェクトが導入され、Kubernetes デプロイメントでの NGINX App Protect の構成にこれらの利点が拡張されます。 このポリシーは、リリース 1.8.0 で導入されたAPLogConfおよびAPPolicyオブジェクトを活用し、VirtualServer (VS) と VSR リソースの両方に添付できます。 つまり、セキュリティ管理者は、VS リソースを使用して Ingress 構成の全範囲に対する所有権を持ち、VSR リソースを参照して他のチームにセキュリティ責任を委任することができます。

次の例では、 waf-prodポリシーがwebapp-prodアップストリームにルーティングされるユーザーに適用されます。 異なるチームが所有する名前空間全体にわたって/v2ルートのセキュリティ責任を委任するために、強調表示されたルートディレクティブは VSR リソースを参照します。

apiバージョン: k8s.nginx.org/v1kind: VirtualServer メタデータ: 名前: webapp 仕様: ホスト: webapp.example.com ポリシー: - 名前: waf-prod tls: シークレット: app-secret アップストリーム: - 名前: webapp-prod サービス: webapp-svc ポート: 80 ルート: - パス: /v2ルート: test/test - パス: /v1 アクション: パス: webapp-prod

テスト名前空間を管理するチームは、その名前空間内の VSR リソースを使用して独自のパラメーターと WAF ポリシーを設定できます。

apiバージョン: k8s.nginx.org/v1kind: VirtualServerRoute
メタデータ:
名前: test
名前空間: test
仕様:
ホスト: webapp.example.com
アップストリーム:
-名前: webapp
サービス: webapp-test-svc
ポート: 80
サブルート:
- パス: /v2
ポリシー:
- 名前: waf-test
アクション:
パス: webapp

この例では、テナントを名前空間ごとに分離し、テスト名前空間のwebapp-test-svcサービスに異なる WAF ポリシーを適用します。 これは、リソースをさまざまなチームに委任し、それらをオブジェクトでカプセル化することで、運用中のアプリケーションを中断することなく、新しい機能のテストが簡素化される方法を示しています。

リリース 1.11.0 のその他の新機能は何ですか?

NGINX Ingress Controller 1.11.0 では、柔軟で強力、そして使いやすいプロダクション グレードの Ingress コントローラーを提供するという当社の取り組みを継続します。 WAF と TS の改善に加えて、リリース 1.11.0 には次の機能強化が含まれています。

• より多くの注釈の検証– より多くの構成エラーを回避
• ポリシーステータス情報– Ingress構成に適用される前のポリシーオブジェクトのステータスを表示します。
• Istio 互換性– Istio 環境で NGINX Ingress Controller の高度な機能を活用
• アップストリームエンドポイントのクラスタIPアドレス– NGINX Ingress Controller構成のアップストリームエンドポイントにサービス/クラスタIPアドレスを入力します。

より多くの注釈の検証

リリース 1.10.0 で導入された注釈検証の改善に基づいて、次の追加の注釈を検証するようになりました。

Ingress リソースが適用されたときにアノテーションの値が有効でない場合、Ingress コントローラーはリソースを拒否し、NGINX から対応する構成を削除します。

ポリシーに関するステータス情報

kubectl get policyコマンドは、ポリシーの状態 (有効または無効) と (単一の TS の場合) カスタム メッセージおよび最新の更新の理由を報告するようになりました。

$ kubectl get policy NAME STATE AGE webapp-policy 有効期間 30 秒 $ kubectl describe policy webapp-policy . . .
状態：
  メッセージ：  default/webapp-policy の構成が追加または更新されました。理由:   追加または更新された状態:    有効

Istioとの互換性

NGINX Ingress Controller は、Istio サービス メッシュ内で実行されているアプリの Ingress コントローラーとして使用できるようになりました。 これにより、ユーザーは回避策に頼ることなく、NGINX Ingress Controller が Istio ベースの環境で提供する高度な機能を引き続き使用できます。 この統合には 2 つの要件があります。

• NGINX Ingress Controller デプロイメントへの Istio サイドカーの挿入
• バックエンドに送信されるHTTPホストヘッダーは1つだけです

最初の要件を満たすには、NGINX Ingress デプロイメント ファイルのアノテーションフィールドに次の項目を含めます。

注釈: traffic.sidecar.istio.io/includeInboundPorts: "" 
traffic.sidecar.istio.io/excludeInboundPorts: 「80,443」traffic.sidecar.istio.io/excludeOutboundIPRanges: "10.90.0.0/16,10.45.0.0/16" sidecar.istio.io/inject: 'true'

2 番目の要件は、 requestHeadersフィールドの動作を変更することで実現されます。 以前のリリースでは、次の構成で 2 つのホストヘッダー ( $hostと指定された値bar.example.com ) がバックエンドに送信されていました。

apiバージョン: k8s.nginx.org/v1kind: VirtualServer メタデータ: 名前: foo 仕様: ホスト: foo.example.com アップストリーム: - 名前: foo ポート: 8080 サービス: backend-svc use-cluster-ip: true ルート: - パス: "/" アクション: プロキシ: アップストリーム: fooリクエストヘッダー: 設定: - 名前: ホスト値: bar.example.com

リリース 1.11.0 以降では、指定された値のみが送信されます。 $host を送信するには、 requestHeadersフィールドを完全に省略します。

上流エンドポイントのクラスタ IP アドレス

NGINX Ingress Controller 構成のアップストリーム エンドポイントに、ポッド エンドポイントの個々の IP アドレスではなく、サービス/クラスター IP アドレスを入力できるようになりました。 NGINX Ingress Controller がトラフィックを Cluster-IP サービスにルーティングできるようにするには、VS または VSR 構成のアップストリームセクションにuse-cluster-ip: trueフィールドを含めます。

アップストリーム: - 名前: tea サービス: tea-svc ポート: 80 use-cluster-ip: true - 名前: coffee サービス: coffee-svc ポート: 80クラスタIPの使用: true

リソース

リリース 1.11.0 の完全な変更ログについては、リリース ノートを参照してください。

NGINX Plus および NGINX App Protect を搭載した NGINX Ingress Controller for Kubernetes を試すには、今すぐ30 日間の無料トライアルを開始するか、お問い合わせの上、ユースケースについてご相談ください。

NGINX Open Source で NGINX Ingress Controller を試すには、リリース ソース コードを入手するか、 DockerHubからビルド済みコンテナーをダウンロードします。

Ingress コントローラーの違いについては、弊社のブログの「待ってください、Kubernetes 用のどの NGINX Ingress コントローラーを使用していますか?」をご覧ください。