【実務・中級編】コンテナネットワークセキュリティ：Service Meshによる相互TLS(mTLS) – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

現場で修羅場をくぐり抜けてきたエンジニア諸君、ようこそ。

今日は、Kubernetes環境における「最後の砦」とも言えるサービスメッシュ（Istio）によるmTLS（相互TLS）について、綺麗事抜きで語らせてもらう。

「コンテナ間通信なんて社内ネットワークなんだから平文でいいだろう」なんて考えているエンジニアがまだいるなら、今すぐ考えを改めてほしい。昨今の攻撃者は、一度クラスタ内に侵入すれば、まずネットワークを嗅ぎ回る。サービス間のトラフィックを盗聴する「中間者攻撃（MitM）」や、偽装されたサービスによる特権情報の奪取は、もはや教科書通りの定石だ。

なぜ「境界防御」だけでは不十分なのか

現代のコンテナ環境において、攻撃者はPod内部の脆弱性や、設定ミスを突いて侵入してくる。一度内部に入り込めば、ファイアウォールやWAFは素通りだ。サービスAとサービスBがHTTPで通信していれば、攻撃者はそのパケットをキャプチャし、機密データを抜いたり、リクエストを改ざんして不正な処理を実行させたりする。

ここで重要になるのが「ゼロトラスト・ネットワーク」の考え方だ。ネットワークを「信頼できないもの」と定義し、通信一つひとつに対して「誰が（ID）」、「何者か（証明書）」を検証する。それをアプリケーションコードを一切いじらずに実現するのが、IstioによるmTLSだ。

mTLS実装の勘所：Istioによる強制化

Istioを導入する最大のメリットは、開発者が暗号化ロジックを実装しなくていい点にある。Envoyサイドカープロキシが勝手にやってくれる。しかし、デフォルト設定のままでは「PERMISSIVE（平文も許容）」になっていることが多い。これでは意味がない。

全通信をmTLSで強制する設定（PeerAuthentication）は、以下の通りだ。

# 攻撃者が暗号化なしの通信を試みても、Istioが即座に拒絶するように設定する
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system # クラスタ全体に適用
spec:
  mtls:
    mode: STRICT # ここを必ずSTRICTにする。PERMISSIVEは甘えだ。

運用でハマる「認証の盲点」：認可ポリシーの併用

mTLSで暗号化しても、単に「通信相手が正しい」ことが証明されるだけだ。その先にある「このサービスは、このAPIを叩いていいのか？」という認可（Authorization）を忘れてはいけない。mTLSと併せて AuthorizationPolicy を書くのがプロの仕事だ。

例えば、frontendからしか叩かれないはずのbackend APIに対し、意図しないPodからのアクセスを遮断する設定がこれだ。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-only-frontend
  namespace: backend-namespace
spec:
  selector:
    matchLabels:
      app: backend-api
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/frontend-namespace/sa/frontend-service-account"]
    to:
    - operation:
        methods: ["GET"] # 最小権限の原則：必要なメソッドだけに絞る
        paths: ["/api/v1/data"]

開発者が知っておくべき「証明書のライフサイクル」

mTLSを運用する上で最も恐ろしいのは、証明書の期限切れだ。Istioは自動で証明書をローテーションしてくれるが、コントロールプレーンがダウンしたり、証明書発行局（CA）の設定が壊れたりすれば、通信は全て遮断される。

現場でのインシデント回避Tips:
1. 監視の徹底: istioctl proxy-status で常にサイドカーの同期状況を監視すること。
2. 証明書の有効期限アラート: Prometheus等を利用して、Istioが発行する証明書の有効期限をメトリクスとして拾い上げ、アラートを設定しておくこと。
3. ロールバック計画: 万が一、証明書周りでトラブルが起きた際、PeerAuthentication を一時的に PERMISSIVE に戻す手順をRunbookとして用意しておけ。

最後に：セキュリティは「入れ物」ではなく「規律」

「mTLSを導入したからもう安心だ」と考えるのは早い。これはあくまで「通信の暗号化と認証」というインフラ層の防御に過ぎない。アプリケーション層では依然としてSQLインジェクションや、過剰な権限を持つAPIの実装によるリスクが残る。

エンジニアとして信頼されるためには、こうしたインフラの堅牢化を前提としつつ、日々のコードから脆弱性を排除する意識を持ち続けてほしい。ツールは魔法ではない。それをどう使いこなし、どのようなポリシーで縛るか。その「規律」こそが、真のセキュリティなのだ。

今日紹介した設定は、明日からの君たちのシステムを確実に強固にするはずだ。早速、開発環境で STRICT モードを試してみてくれ。何かあればまた相談に乗る。健闘を祈る。