TLS構成の理解

5分の読み時間

Istioの最も重要な機能の1つは、メッシュへの、メッシュからの、そしてメッシュ内のネットワークトラフィックをロックダウンし、保護する機能です。ただし、TLS設定の構成は混乱を招きやすく、設定ミスが発生しやすい原因となっています。このドキュメントでは、Istioでリクエストを送信する際に発生するさまざまな接続と、それらに関連するTLS設定の構成方法について説明します。TLS構成の間違いでは、最も一般的なTLS構成の問題の概要を説明しています。

サイドカー

サイドカーのトラフィックには、さまざまな関連する接続があります。一つずつ見ていきましょう。

Sidecar proxy network connections — サイドカープロキシのネットワーク接続

外部インバウンドトラフィック これは、サイドカーによってキャプチャされた外部クライアントからのトラフィックです。クライアントがメッシュ内にある場合、このトラフィックはIstio相互TLSで暗号化される可能性があります。デフォルトでは、サイドカーはmTLSと非mTLSの両方のトラフィックを受け入れるように構成されます。これはPERMISSIVEモードと呼ばれます。モードは、トラフィックがmTLSでなければならないSTRICT、またはトラフィックがプレーンテキストでなければならないDISABLEに構成することもできます。mTLSモードは、PeerAuthenticationリソースを使用して構成されます。
ローカルインバウンドトラフィック これは、サイドカーからアプリケーションサービスへのトラフィックです。このトラフィックは常にそのまま転送されます。これは常にプレーンテキストであるという意味ではないことに注意してください。サイドカーはTLS接続をパススルーする場合があります。つまり、サイドカーから新しいTLS接続が開始されることは決してないということです。
ローカルアウトバウンドトラフィック これは、サイドカーによってインターセプトされたアプリケーションサービスからの発信トラフィックです。アプリケーションは、プレーンテキストまたはTLSトラフィックを送信している可能性があります。自動プロトコル選択が有効になっている場合、Istioはプロトコルを自動的に検出します。それ以外の場合は、宛先サービスでポート名を使用して、プロトコルを手動で指定する必要があります。
外部アウトバウンドトラフィック これは、サイドカーから外部宛先への発信トラフィックです。トラフィックはそのまま転送することも、TLS接続を開始（mTLSまたは標準TLS）することもできます。これは、DestinationRuleリソースのtrafficPolicyのTLSモード設定を使用して制御されます。モード設定がDISABLEの場合、プレーンテキストが送信されます。一方、SIMPLE、MUTUAL、およびISTIO_MUTUALの場合、TLS接続が開始されます。

重要なポイントは次のとおりです。

PeerAuthenticationは、サイドカーが受け入れるmTLSトラフィックのタイプを構成するために使用されます。
DestinationRuleは、サイドカーが送信するTLSトラフィックのタイプを構成するために使用されます。
ポート名または自動プロトコル選択によって、サイドカーがトラフィックを解析するプロトコルが決まります。

自動mTLS

上記のように、DestinationRuleは、発信トラフィックがmTLSを使用するかどうかを制御します。ただし、これをすべてのワークロードに対して構成するのは面倒な場合があります。通常、可能な限りIstioに常にmTLSを使用させ、メッシュの一部ではないワークロード（つまり、サイドカーのないワークロード）にのみプレーンテキストを送信するようにします。

Istioでは、「自動mTLS」と呼ばれる機能により、これが簡単になります。自動mTLSは、まさにそれを行うことで機能します。DestinationRuleでTLS設定が明示的に構成されていない場合、サイドカーはIstio相互TLSを送信する必要があるかどうかを自動的に判断します。つまり、構成なしで、すべてのメッシュ間トラフィックがmTLSで暗号化されるということです。

ゲートウェイ

ゲートウェイへの任意のリクエストには、2つの接続があります。

Gateway network connections — ゲートウェイのネットワーク接続

curlやWebブラウザなどの一部のクライアントによって開始されたインバウンドリクエスト。これは多くの場合、「ダウンストリーム」接続と呼ばれます。
ゲートウェイから一部のバックエンドに開始されたアウトバウンドリクエスト。これは多くの場合、「アップストリーム」接続と呼ばれます。

これらの両方の接続には、独立したTLS構成があります。

イングレスゲートウェイとエグレスゲートウェイの構成は同一であることに注意してください。istio-ingress-gatewayとistio-egress-gatewayは、2つの特化したゲートウェイデプロイメントにすぎません。違いは、イングレスゲートウェイのクライアントがメッシュの外部で実行されているのに対し、エグレスゲートウェイの場合は宛先がメッシュの外部にあることです。

インバウンド

インバウンドリクエストの一部として、ゲートウェイはルーティングルールを適用するためにトラフィックをデコードする必要があります。これは、Gatewayリソースのサーバー構成に基づいて行われます。たとえば、インバウンド接続がプレーンテキストHTTPの場合、ポートプロトコルはHTTPとして構成されます。

apiVersion: networking.istio.io/v1
kind: Gateway
...
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP

同様に、生のTCPトラフィックの場合、プロトコルはTCPに設定されます。

TLS接続の場合、いくつかのオプションがあります。

カプセル化されているプロトコルは何ですか？接続がHTTPSの場合、サーバープロトコルはHTTPSとして構成する必要があります。それ以外の場合は、TLSでカプセル化された生のTCP接続の場合、プロトコルをTLSに設定する必要があります。
TLS接続は終了されますか、それともパススルーされますか？パススルートラフィックの場合、TLSモードフィールドをPASSTHROUGHに構成します。
```
apiVersion: networking.istio.io/v1
kind: Gateway
...
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: PASSTHROUGH
```
このモードでは、IstioはSNI情報に基づいてルーティングし、接続をそのまま宛先に転送します。
相互TLSを使用する必要がありますか？相互TLSは、TLSモードMUTUALを介して構成できます。これを構成すると、クライアント証明書が要求され、構成済みのcaCertificatesまたはcredentialNameに対して検証されます。
```
apiVersion: networking.istio.io/v1
kind: Gateway
...
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: MUTUAL
      caCertificates: ...
```

アウトバウンド

インバウンド側は、どのようなタイプのトラフィックを予期し、どのように処理するかを構成しますが、アウトバウンド構成は、ゲートウェイが送信するトラフィックのタイプを制御します。これは、サイドカーからの外部アウトバウンドトラフィックと同様に、DestinationRuleのTLS設定、またはデフォルトで自動mTLSによって構成されます。

唯一の違いは、これを構成する際にGatewayの設定を考慮する必要があることです。たとえば、GatewayがTLS PASSTHROUGHで構成され、DestinationRuleがTLSの発信を構成している場合、二重暗号化になる可能性があります。これは機能しますが、多くの場合、望ましい動作ではありません。

ゲートウェイにバインドされたVirtualServiceも、Gatewayの定義と一致するように注意する必要があります。