相互TLSが有効になっていることの確認
アンビエントメッシュにアプリケーションを追加したら、以下のいずれかの方法を使用して、ワークロード間でmTLSが有効になっていることを簡単に検証できます。
ワークロードのztunnel設定を使用してmTLSを検証する
便利な `istioctl ztunnel-config workloads` コマンドを使用すると、 `PROTOCOL` 列の値によって、ワークロードがHBONEトラフィックを送受信するように設定されているかどうかを確認できます。例：
$ istioctl ztunnel-config workloads
NAMESPACE POD NAME IP NODE WAYPOINT PROTOCOL
default details-v1-857849f66-ft8wx 10.42.0.5 k3d-k3s-default-agent-0 None HBONE
default kubernetes 172.20.0.3 None TCP
default productpage-v1-c5b7f7dbc-hlhpd 10.42.0.8 k3d-k3s-default-agent-0 None HBONE
default ratings-v1-68d5f5486b-b5sbj 10.42.0.6 k3d-k3s-default-agent-0 None HBONE
default reviews-v1-7dc5fc4b46-ndrq9 10.42.1.5 k3d-k3s-default-agent-1 None HBONE
default reviews-v2-6cf45d556b-4k4md 10.42.0.7 k3d-k3s-default-agent-0 None HBONE
default reviews-v3-86cb7d97f8-zxzl4 10.42.1.6 k3d-k3s-default-agent-1 None HBONE
ワークロードでHBONEが設定されているからといって、ワークロードがプレーンテキストトラフィックを拒否するわけではありません。ワークロードにプレーンテキストトラフィックを拒否させたい場合は、ワークロードのmTLSモードを `STRICT` に設定した `PeerAuthentication` ポリシーを作成します。
メトリクスからmTLSを検証する
Prometheusをインストールしている場合は、ポートフォワーディングを設定し、次のコマンドを使用してPrometheus UIを開くことができます。
$ istioctl dashboard prometheus
Prometheusでは、TCPメトリクスの値を表示できます。最初に、グラフを選択し、 `istio_tcp_connections_opened_total`、 `istio_tcp_connections_closed_total`、 `istio_tcp_received_bytes_total`、または `istio_tcp_sent_bytes_total` などのメトリックを入力します。最後に、実行をクリックします。データには次のようなエントリが含まれます。
istio_tcp_connections_opened_total{
app="ztunnel",
connection_security_policy="mutual_tls",
destination_principal="spiffe://cluster.local/ns/default/sa/bookinfo-details",
destination_service="details.default.svc.cluster.local",
reporter="source",
request_protocol="tcp",
response_flags="-",
source_app="curl",
source_principal="spiffe://cluster.local/ns/default/sa/curl",source_workload_namespace="default",
...}
`connection_security_policy` の値が `mutual_tls` に設定されており、予期される送信元と送信先のID情報とともに設定されていることを確認します。
ログからmTLSを検証する
送信元または送信先のztunnelログを表示して、mTLSが有効になっていることと、ピアIDを確認することもできます。以下は、 `curl` サービスから `details` サービスへのリクエストに対する送信元ztunnelのログの例です。
2024-08-21T15:32:05.754291Z info access connection complete src.addr=10.42.0.9:33772 src.workload="curl-7656cf8794-6lsm4" src.namespace="default"
src.identity="spiffe://cluster.local/ns/default/sa/curl" dst.addr=10.42.0.5:15008 dst.hbone_addr=10.42.0.5:9080 dst.service="details.default.svc.cluster.local"
dst.workload="details-v1-857849f66-ft8wx" dst.namespace="default" dst.identity="spiffe://cluster.local/ns/default/sa/bookinfo-details"
direction="outbound" bytes_sent=84 bytes_recv=358 duration="15ms"
src.identity と dst.identity の値が正しいことを確認してください。これらは、送信元と宛先のワークロード間の mTLS 通信に使用される ID です。詳細は、ztunnel トラフィックのログによる検証セクションを参照してください。
Kialiダッシュボードで検証する
Kiali と Prometheus がインストールされている場合は、Kiali のダッシュボードを使用して、アンビエントメッシュ内のワークロード通信を視覚化できます。ワークロード間の接続に南京錠アイコンが表示されているかどうかを確認することで、mTLS が有効になっていることと、ピアID情報を確認できます。
詳細は、アプリケーションとメトリクスの視覚化ドキュメントを参照してください。
`tcpdump` で検証する
Kubernetes ワーカーノードにアクセスできる場合は、tcpdump コマンドを実行して、ネットワークインターフェース上のすべてのトラフィックをキャプチャできます。オプションで、アプリケーションポートと HBONE ポートに焦点を絞ることもできます。この例では、ポート 9080 は details サービスポート、15008 は HBONE ポートです。
$ tcpdump -nAi eth0 port 9080 or port 15008
tcpdump コマンドの出力には、暗号化されたトラフィックが表示されます。
ワーカーノードにアクセスできない場合は、netshoot コンテナイメージを使用して、コマンドを簡単に実行できる場合があります。
$ POD=$(kubectl get pods -l app=details -o jsonpath="{.items[0].metadata.name}")
$ kubectl debug $POD -i --image=nicolaka/netshoot -- tcpdump -nAi eth0 port 9080 or port 15008