ingress-nginxのSSL Passthroughとは?設定方法と通信の仕組み・注意点

目次

はじめに

「ingress-nginxでSSL Passthroughを使いたいけれど、どこを設定すればいいの?」
「HTTPS通信をそのままバックエンドへ渡すと、通常のTLS終端と何が変わるの?」と迷っていませんか。

Kubernetes環境でingress-nginxを使ってHTTPS通信を構成すると、IngressでSSLを終端する方法だけでなく、暗号化された通信をバックエンドのサービスまでそのまま転送するSSL Passthroughという仕組みもあります。

この記事では、ingress-nginxのSSL Passthroughがどのように通信を転送するのか、必要な設定方法や通常のTLS終端との違い、利用時に確認したい注意点まで、順を追って説明していきます。

ingress-nginxのSSL Passthroughとは?

ingress-nginxのSSL Passthroughは、IngressでTLS通信を復号せず、そのままバックエンドのサービスへ転送する方式です。

ここでは、SSL Passthroughがどのように通信を処理する方式なのかを説明します。

SSL Passthrough

SSL Passthroughは、クライアントからのTLS通信をIngressで復号せず、暗号化したままバックエンドへ転送する方式です。

TLS終端はバックエンド側で行うため、IngressではHTTPとして処理せず、バックエンドがHTTPS通信を受け取ります。

ingress-nginxでSSL Passthroughを設定する方法

ingress-nginxでSSL Passthroughを利用するには、Ingress Controllerで機能を有効にしたうえで、IngressリソースにPassthroughの設定を追加し、バックエンドでHTTPS通信を受けられる状態にする必要があります。

ここでは、Ingress Controller、Ingress、バックエンドの順に設定方法を説明します。

Ingress ControllerでSSL Passthroughを有効にする

SSL Passthroughを利用するには、まずIngress Controller側で機能を有効にします。

ingress-nginxでは、Controllerの起動引数に「–enable-ssl-passthrough」を指定します。

この設定がないと、Ingress側でPassthroughを指定してもTLS通信をそのまま転送できません。

IngressにSSL Passthroughを設定する

Ingressリソースには、「nginx.ingress.kubernetes.io/ssl-passthrough: “true”」のアノテーションを追加します。

これにより、対象のTLS通信をIngressで終端せず、暗号化したままバックエンドへ転送できます。

Controller側の設定とあわせて有効にしておきましょう。

バックエンド側でHTTPSを受けられるようにする

バックエンド側では、転送されたTLS通信を受け取れるようにHTTPSを設定します。

HTTPSを待ち受けるポートを用意し、IngressからServiceを経由して接続できる状態にします。

設定後は、バックエンドまでHTTPS通信が届いているか確認しておくと安心です。

SSL Passthroughの通信はどう動く?

SSL Passthroughでは、クライアントから送られたHTTPS通信をingress-nginxが受け取り、TLSを終端せずにバックエンドへ転送します。

ここでは、クライアントからingress-nginxを経由してバックエンドへTLS通信が届くまでの流れを順に説明します。

クライアントからのHTTPS通信をingress-nginxが受け取る

クライアントがHTTPSで接続すると、TLS通信がingress-nginxに到達します。

SSL PassthroughではTLS通信をIngress側で復号せず、暗号化された状態のまま扱います。

そのため、TLSハンドシェイクはバックエンド側で行われます。

SNIで転送先を判定してバックエンドへTLS通信を渡す

ingress-nginxは、TLS通信に含まれるSNIのホスト名から転送先のバックエンドを判定します。

判定後はTLS通信を復号せず、そのまま対象のバックエンドへ転送します。

バックエンド側でTLSを終端し、HTTPS通信を処理する仕組みです。

SSL Passthroughを使うときの注意点

SSL Passthroughを利用すると、TLS通信をバックエンドまでそのまま転送できる一方で、通常のリバースプロキシとは異なる制約があります。

ここでは、HTTPレイヤーの制約、性能面の注意点、バックエンドで必要になるHTTPS管理について説明します。

HTTPレイヤーの機能やヘッダー操作に制約がある

SSL PassthroughではTLS通信を復号しないため、ingress-nginxからHTTPリクエストの内容を確認できません。

そのため、HTTPヘッダーの追加や書き換えなど、HTTPレイヤーの機能を利用しにくくなります。

これらの処理が必要な場合は、IngressでTLSを終端する構成も検討しましょう。

Ingress側でHTTP処理も行いたい場合は、SSL Passthroughとの違いを整理しておくと構成を判断しやすくなります。
▶SSL終端とは?仕組みや設定方法をわかりやすく解説

通常のリバースプロキシより性能面で注意が必要

SSL PassthroughではTLSをバックエンド側で終端するため、それぞれのバックエンドでTLS処理の負荷がかかります。

アクセスや同時接続が増える環境では、CPU使用率や接続数への影響にも注意が必要です。

導入後は負荷の状況を確認しながら運用すると安心です。

バックエンド側で証明書とHTTPSを管理する必要がある

SSL Passthroughでは、バックエンド側でHTTPSの設定や証明書を管理します。

証明書の配置や更新、秘密鍵の管理も必要になるため、期限切れや設定ミスには注意しましょう。

バックエンドごとに証明書とHTTPSの設定を確認しておくことが大切です。

バックエンドで証明書を管理する場合は、更新時のトラブルを防ぐためにSSL証明書の更新方法も確認しておくと安心です。
▶SSL証明書の更新方法は?手順や反映されないときの確認ポイントを解説

SSL PassthroughとTLS終端はどう使い分ける?

SSL PassthroughとTLS終端では、TLS通信をどこで復号して処理するかが異なるため、バックエンドでHTTPSを処理するのか、IngressでHTTP処理まで行うのかによって設定を分ける必要があります。

ここでは、それぞれの構成に適した使い分け方を説明します。

バックエンドでTLSを処理したい場合はSSL Passthroughを使う

バックエンドでTLSを終端し、証明書やHTTPSを管理したい場合はSSL Passthroughを使います。

ingress-nginxではTLS通信を復号せず、暗号化したままバックエンドへ転送します。

そのため、バックエンド側でHTTPSを受け付ける設定と証明書の管理が必要です。

IngressでTLSを終端してHTTP処理したい場合は通常のTLS設定を使う

IngressでTLSを終端し、HTTPヘッダーの操作などを行いたい場合は通常のTLS設定を使います。

TLS通信をIngress側で復号してからバックエンドへ転送するため、証明書はIngress側で管理できます。

そのため、バックエンドでTLSを終端する必要がない構成では管理しやすくなります。

まとめ

SSL Passthroughは、IngressでTLSを終端せず、暗号化した通信をそのままバックエンドへ届けたい場合に使う仕組みです。

バックエンド側で証明書やHTTPSを管理したいときに便利ですが、HTTPヘッダーの操作など、Ingress側で利用できない機能もあります。

どこでTLSを終端したいのかを整理し、HTTP処理も含めて構成に合った方法を選びましょう。

よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

目次