TLS 通信では、クライアントはサーバーの証明書を検証しますが、クライアントは証明書を提供しないため、サーバーはクライアントを認証しません。セキュリティの向上が求められるシナリオでは、サーバーもクライアントの ID を検証する必要があります。そのためには、mTLS 通信を使用する必要があります。 mTLS では、クライアントとサーバーの両方が証明書を提示し、相互検証後にのみ暗号化通信を許可します。このトピックでは、ASM を使用して環境にエンドツーエンドの mTLS 通信を実装する方法について説明します。
背景情報
ASM を使用すると、アプリケーションを変更することなく、mTLS を使用してエンドツーエンドのトラフィックを暗号化できます。さらに、各段階で mTLS によって提供される証明書を利用してアクセス制御を行うことができます。このアプローチは、ビジネス全体のセキュリティを強化します。
Kubernetes 環境では、エンドツーエンドには通常、次の 3 つの段階が含まれます。
イングレストラフィック: クラスタ外のクライアントがクラスタ内のサービスにアクセスします。
East-West トラフィック: クラスタ内のワークロード間の East-West トラフィック。
エグレストラフィック: クラスタ内のワークロードがクラスタ外のサービスにアクセスします。
ASM を使用してエンドツーエンドの mTLS を実装することには、次の利点があります。
アプリケーションはビジネスロジックに集中し、セキュリティ機能をサービスメッシュインフラストラクチャに委任できるため、ビジネスの反復が加速します。
ASM は、クラスタ内の通信用の証明書の発行とローテーションを管理するため、メンテナンスの負担が大幅に軽減されます。
移行中にビジネスアプリケーションを変更する必要がないため、移行がスムーズになります。
mTLS を使用してイングレストラフィックを暗号化する
クラスタ外のクライアントがクラスタ内のサービスにアクセスする場合、ASMイングレスゲートウェイを経由する必要があります。詳細については、「ASMイングレスゲートウェイで mTLS サービスを構成し、特定のクライアントアクセスを制限する」をご参照ください。
mTLS を使用して East-West トラフィックを暗号化する
East-West トラフィックの mTLS 通信は、ASM によって提供される基本機能の 1 つであり、追加の構成は必要ありません。クラスタ内の通信の両側にサイドカープロキシを挿入するだけです。詳細については、「サイドカープロキシをインストールする」をご参照ください。
サイドカープロキシが挿入された 2 つのポッド間の通信は、自動的に mTLS にアップグレードされ、アプリケーションを変更する必要はありません。さらに、どちらも ASM コントロールプレーンに接続されているため、ASMイングレス/エグレスゲートウェイとサイドカープロキシ間の通信も自動的に mTLS 暗号化を使用します。
mTLS 通信で使用される証明書は、ワークロードで使用される ServiceAccount に基づいて発行され、ASM コントロールプレーンによって定期的にローテーションされるため、手動による介入は必要ありません。
ビジネスを ASM に段階的に移行しやすくするために、ASM はピア ID 認証構成を提供します。移行プロセス中に、ピア ID 認証レベルを PERMISSIVE（プレーンテキストと mTLS トラフィックの両方を受け入れる）に調整できます。移行が完了したら、ピア ID 認証レベルを STRICT（mTLS トラフィックのみを受け入れる）に変更して、クラスタ内のすべてのトラフィックが mTLS を使用して暗号化されるようにすることができます。
mTLS を使用してエグレストラフィックを暗号化する
クラスタ外にアクセスに mTLS を必要とするサービスがある場合でも、アプリケーションはプレーンテキストのリクエストを開始できます。ASMエグレスゲートウェイは、これらのプレーンテキストリクエストを mTLS にアップグレードして、外部サービスに転送できます。詳細については、「ASMエグレスゲートウェイを使用して外部 mTLS サービスにアクセスする」をご参照ください。