[Istio] イングレスゲートウェイのセキュリティの核心: TLS SIMPLE vs MUTUAL モード完全解説 🛡️

こんにちは！今日は、Kubernetesサービスメッシュの標準であるIstio（イスティオ）を扱う上で最も重要でありながら、混同しやすいGatewayのTLSモードについてお話したいと思います。

外部からのトラフィックを安全にクラスタに受け入れるためには、セキュアな接続（HTTPS）が不可欠です。Istio Gatewayでは、このセキュリティレベルをどのように調整するのでしょうか？

最もよく使われるSIMPLEモードとMUTUALモードの違い、そして設定過程でよく遭遇するCLIエラーの解決策まで、非常に詳しく掘り下げていきます。🚀

---

1. ちょっと待って！シークレット作成中にエラーが出ましたか？ 🚨

Istioゲートウェイに証明書を適用するには、まずKubernetes Secretを作成する必要があります。しかし、以下のようなエラーに遭遇することがよくあります。

error: flag needs an argument: --from-file
bash: tls.crt=/root/certificates/booking.example.com.crt: No such file or directory

これは通常、コマンドが長くなる際に改行（Enter）処理を誤って行った場合に発生します。ターミナルはバックスラッシュ（）なしで改行すると、コマンドが終了したと判断して実行してしまうためです。

✅ 正しい解決策

オプションを一行で記述するか、改行する際には必ずを付けてください。特にmTLSのためには、CA証明書（ca.crt）も一緒に含めることを忘れないでください！

# mTLS用シークレット作成例（一行でスッキリ！）
kubectl create secret generic booking-credential-mutual -n istio-system 
  --from-file=ca.crt=/root/certificates/example.com.crt 
  --from-file=tls.crt=/root/certificates/booking.example.com.crt 
  --from-file=tls.key=/root/certificates/booking.example.com.key

さあ、これで材料（証明書）が揃ったので、料理（TLSモード設定）を始めましょうか？👨‍🍳

---

2. mode: SIMPLE (単方向TLS) 🌐

SIMPLEモードは、私たちが普段インターネットサーフィンをする際に出会う標準的なHTTPS方式です。

💡 動作原理

この方式は「サーバー（Gateway）だけが身分証を提示」します。

1. Client（ユーザー） ➡️ Gateway: 「接続させてください。」
2. Gateway ➡️ Client: 「はい、私がそのサイト（Server）です。私の証明書を確認してください。」 📜
3. Client: 「ふむ、信頼できる機関（CA）から発行されているな。合格！」 ✅
4. 🔒 暗号化通信開始

🎯 特徴と用途

• ゲートウェイはクライアントが誰であるかを検査しません。（誰でも接続可能）
• 用途: 一般的なウェブサービス、ショッピングモール、ブログなど、一般に公開されたサービス。

📝 YAML設定例

サーバーの証明書とキーが含まれたシークレット（credentialName）のみを指定すればOKです。

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: my-simple-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - "example.com"
    tls:
      mode: SIMPLE  # 👈 ここ！
      credentialName: booking-credential # サーバー証明書（tls.crt, tls.key）のみでOK

---

3. mode: MUTUAL (双方向TLS / mTLS) 🤝

MUTUALモードは、セキュリティがはるかに強化された方式です。名前の通り「お互い（Mutual）」に認証します。一般的にmTLSと呼ばれます。

💡 動作原理

この方式は「サーバーとクライアントの両方が身分証を交換」します。

1. Client ➡️ Gateway: 「接続リクエスト！」
2. Gateway ➡️ Client: 「まず私の身分証（Server Cert）を確認してください。」 📜
3. Gateway ➡️ Client: 「ところであなたは誰ですか？あなたの身分証（Client Cert）も見せてください。」 👮‍♂️
4. Client ➡️ Gateway: 「こちらが私の証明書です。」 🪪
5. Gateway: （持っているCA証明書で検証）「おお、当社のパートナーですね。通過！」 ✅
6. 🔒 双方向暗号化通信開始

🎯 特徴と用途

• クライアントも必ず有効な証明書がなければ接続できません。（ない場合は400エラーなどで拒否されます）
• 用途: 金融機関API、パートナー企業専用システム、内部管理者ページ、IoT機器通信など、信頼された対象のみが接続すべき場合。

📝 YAML設定例

ここでは、サーバー証明書だけでなく、クライアントを検証するためのCA証明書がシークレットに必ず含まれている必要があります。

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: my-mutual-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - "booking.example.com"
    tls:
      mode: MUTUAL  # 👈 強力なセキュリティ！
      credentialName: booking-credential-mutual # ここにはca.crtが必須！

---

4. 一目で要約 📊

区分	SIMPLE (単方向)	MUTUAL (双方向)
認証主体	クライアントがサーバーを検証	お互いが相手を検証
クライアントの準備物	なし（ブラウザがあればOK）	クライアント証明書(Client Cert)
ゲートウェイの準備物	サーバー証明書 + キー	サーバー証明書 + キー + CA証明書
セキュリティ強度	通常（データ暗号化）	最高（データ暗号化 + アクセス制御）
推奨シナリオ	公開ウェブサイト	セキュリティが重要な内部/B2Bシステム

—

🏁 終わりに

Istioを導入する大きな理由の一つが、まさにこの強力なセキュリティ機能です。

• 一般ユーザーにサービスを提供する場合 👉 SIMPLE
• 検証済みのシステム間のみで通信する必要がある場合 👉 MUTUAL

この2つを状況に応じて使い分けることが、Istioセキュリティの第一歩です。今日のまとめが、皆さんの安全なクラスタ構築に役立つことを願っています！お読みいただきありがとうございました。😊

---