CLOUD SECURITY LAB

自動 vs 手動: Istio mTLS 証明書管理、あなたの選択は？ 🧐

—

by

cslab
in

マイクロサービスアーキテクチャ（MSA）環境におけるサービス間通信のセキュリティは、いくら強調してもしすぎることはありません。サービスメッシュの代表格であるIstioは、mTLS（相互TLS）を通じてこの問題を非常に優雅に解決します。まるで各サービスに目に見えない警護員を付けているようなものです。💂‍♂️💂‍♀️

しかし、IstioでmTLSを設定する際、ISTIO_MUTUALとMUTUALという2つのモードに出会います。名前が似ているので同じものかと思ったり、微妙な違いがあるようにも感じたりします。

今日は、この2つのモードの決定的な違いと、いつどちらのモードを使用すべきかを明確に掘り下げていきます！

TL;DR: 主要な要約 📝

  • ISTIO_MUTUAL: Istioが自動的に証明書を発行・管理する方式（利便性 ✨）
  • MUTUAL: ユーザーが直接証明書を準備して提供する必要がある方式（柔軟性/制御力 🔑）

🤔 ISTIO_MUTUAL: すべてをIstioに任せましょう！

ISTIO_MUTUALは、Istioを使用する上で最も標準的で推奨されるmTLS方式です。

このモードを使用すると、Istioのコントロールプレーンに組み込まれたCA（認証局）、つまりistiodがすべてを自動的に処理してくれます。

  1. 自動証明書発行: 新しいワークロード（Pod）が作成されると、istiodがそのワークロードのサービスアイデンティティに合った証明書を自動的に発行します。
  2. 安全な配布: 発行された証明書と秘密鍵をサイドカープロキシ（Envoy）に安全に伝達します。
  3. 自動更新（Rotation）: 証明書の有効期限が近づくと、既存の証明書を自動的に新しい証明書に交換し、サービス中断なしにセキュリティを維持します。⚙️

利点:

  • 圧倒的な利便性: 証明書の生成、管理、更新について一切心配する必要がありません。「mTLSを有効にして！」と言うだけで済みます。
  • 強力なセキュリティ: Istioが検証済みの方法でプロセス全体を自動化するため、人為的なミスによるセキュリティ事故の可能性が減少します。

ほとんどの場合、ISTIO_MUTUALを使用することになり、これだけで十分に強力なセキュリティを構築できます。

YAML設定例

PeerAuthenticationリソースを使用して、特定のネームスペース（default）のすべてのワークロードにISTIO_MUTUALモードを適用する例です。

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: "default-mtls"
  namespace: "default"
spec:
  mtls:
    mode: ISTIO_MUTUAL

はい、これだけです！本当に簡単でしょう？ 😉

🧐 MUTUAL: 自分で管理します！

MUTUALモードは、ユーザーが直接証明書管理の責任を負う必要がある場合に使用します。

どのような場合に必要でしょうか？

  • 会社にすでに独自に構築して使用している外部CA（プライベートCA）がある場合
  • セキュリティ規制上、特定のCAが発行した証明書のみを使用する必要があるコンプライアンス要件がある場合
  • 証明書のライフサイクルや仕様を完全に制御したい場合

このモードを使用するには、ユーザーは以下のものを直接準備してワークロードに提供する必要があります。

  • サーバー証明書 (tls.crt)
  • サーバー秘密鍵 (tls.key)
  • CAチェーン証明書 (ca.crt)

これらのファイルをKubernetes Secretとして作成し、ワークロードにマウントし、IstioにこのSecretを使用するように指示する必要があります。

欠点:

  • 高い管理コスト: 証明書の生成、Secretの管理、定期的な更新まで、すべて手動で処理する必要があります。🥵
  • 複雑性の増加: 設定プロセスが複雑で、証明書管理を誤るとサービス障害やセキュリティ脆弱性につながる可能性があります。

YAML設定例

MUTUALモードは、クライアントが特定の宛先（サーバー）と通信する際に使用する証明書を指定するDestinationRuleで主に使用されます。

1. まず、準備した証明書ファイルでSecretを作成します。

# httpbin-credential という名前のSecretを作成
kubectl create -n default secret tls httpbin-credential 
--key=client.key.pem 
--cert=client.cert.pem 
--cacert=ca.cert.pem

2. DestinationRuleでMUTUALモードとSecretを指定します。

httpbin.default.svc.cluster.localサービスへのリクエストを送信する際に、先ほど作成したhttpbin-credential Secretの証明書を使用するように設定する例です。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: "egress-mtls-httpbin"
  namespace: "default"
spec:
  host: httpbin.default.svc.cluster.local
  trafficPolicy:
    tls:
      mode: MUTUAL
      credentialName: httpbin-credential # 1で作成したSecretの名前
      sni: httpbin.default.svc.cluster.local

ISTIO_MUTUALに比べて、明らかに手間がかかることがわかります。

全体像で見る: いつ何を選択すべきか？

2つのモードの違いを理解したら、全体的な観点からいつどちらを選択すべきかを決定できます。

特徴 ISTIO_MUTUAL MUTUAL
証明書管理主体 Istio (istiod) 🤖 ユーザー 🙋‍♂️
設定の複雑さ 低い（簡単） 高い（複雑）
管理の利便性 非常に高い 低い
使用事例 一般的なサービスメッシュ環境、迅速なセキュリティ適用 既存のPKIインフラ連携、厳格なセキュリティ規制遵守
推奨対象 ほとんどのユーザー 特定の要件を持つ上級ユーザー

結局、選択の基準は「誰が証明書を制御すべきか？」です。

Istioの自動化されたエコシステムにすべてを任せたい場合はISTIO_MUTUALを、既存のセキュリティポリシーとインフラにIstioを統合する必要がある場合はMUTUALを選択すればよいでしょう。

結論 🚀

ISTIO_MUTUALとMUTUALは、単に名前が似ているだけでなく、証明書管理の責任主体が誰にあるかを決定する非常に重要な設定です。

  • ISTIO_MUTUAL: Istioが提供する強力な自動化の恩恵を享受してください。
  • MUTUAL: 外部CA連携など、特別な要件がある場合に使用してください。

ご自身の環境と要件を正確に把握し、適切なmTLSモードを選択して、より安全で信頼性の高いマイクロサービス環境を構築してください！

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です