セキュリティ FAQ

認証ポリシーと宛先ルールを使用すると、サービスの相互TLS設定をいつでも変更できます。詳細については、タスクを参照してください。

認証ポリシーは、メッシュ全体（メッシュ内のすべてのサービスに影響）、名前空間全体（同じ名前空間内のすべてのサービス）、またはサービス固有にすることができます。クラスタ内のサービスの相互TLSを設定するためのポリシーを、任意の方法で持つことができます。

values.global.proxy.privileged=trueでIstioをインストールした場合、tcpdumpを使用して暗号化ステータスを確認できます。また、Kubernetes 1.23以降では、Istioを特権付きでインストールする代わりに、エフェメラルコンテナでkubectl debugを使用してtcpdumpを実行できます。手順については、Istio相互TLS移行を参照してください。

STRICT相互TLSが有効になっている場合、非Istioワークロードは有効なIstioクライアント証明書がないため、Istioサービスと通信できません。

これらのクライアントを許可する必要がある場合、相互TLSモードをPERMISSIVEに構成して、プレーンテキストと相互TLSの両方を許可できます。これは、個々のワークロードまたはメッシュ全体に対して行うことができます。

詳細については、認証ポリシーを参照してください。

相互TLSが有効になっている場合、kubeletにはIstioが発行した証明書がないため、kubeletからのHTTPおよびTCPヘルスチェックは変更なしでは機能しません。

いくつかのオプションがあります。

1. プローブの書き換えを使用して、livenessおよびreadinessリクエストをワークロードに直接リダイレクトします。詳細については、プローブの書き換えを参照してください。これはデフォルトで有効になっており、推奨されています。

2. ヘルスチェックに別のポートを使用し、通常のサービスポートでのみ相互TLSを有効にします。詳細については、Istioサービスのヘルスチェックを参照してください。

3. ワークロードにPERMISSIVEモードを使用します。これにより、プレーンテキストと相互TLSトラフィックの両方を受け入れることができます。このオプションでは相互TLSが強制されないことに注意してください。

Kubernetesで実行されているワークロードの場合、Istio証明書の有効期間はデフォルトで24時間です。

この構成は、プロキシ構成のproxyMetadataフィールドをカスタマイズすることでオーバーライドできます。例：

proxyMetadata:
  SECRET_TTL: 48h

いいえ。traffic.sidecar.istio.io/excludeInboundPortsがサーバーワークロードで使用されている場合、IstioはクライアントEnvoyにデフォルトで相互TLSを送信するように構成します。これを変更するには、相互TLSモードがDISABLEに設定された宛先ルールを構成して、クライアントがこれらのポートにプレーンテキストを送信するようにする必要があります。

Istioをインストールした後、MySQLが接続できない場合があります。これは、MySQLがサーバーファーストプロトコルであり、Istioのプロトコル検出を妨げる可能性があるためです。特に、PERMISSIVEmTLSモードを使用すると、問題が発生する可能性があります。ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0のようなエラーメッセージが表示される場合があります。

これは、STRICTまたはDISABLEモードが使用されているか、すべてのクライアントがmTLSを送信するように構成されていることを確認することで修正できます。詳細については、サーバーファーストプロトコルを参照してください。

はい。Istioは、メッシュ内のHTTPおよびプレーンTCPサービスの両方に認可機能を提供します。詳細はこちら。

安全なイングレストラフィックタスクの手順に従うことで、TLSトラフィックのみを受け入れるようにIstio Ingressを保護できます。

はい、できます。相互TLSが有効になっている場合と無効になっている場合の両方で機能します。