【実務・中級編】 Kubernetesにおけるサービスメッシュ(Istio/Linkerd)による相互TLS(mTLS) – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

おい、聞いてくれ。先日、あるクライアントのKubernetesクラスタでインシデントレスポンスの支援に入ったんだ。
「うちはクラウド基盤上で動いているし、プライベートサブネットだから大丈夫」「CNI（Container Network Interface）でカプセル化しているから平文通信でも盗聴されない」――そんな甘い認識を持っていた開発チームが、見事にやられていた。

侵入経路は、エッジで動いていた古いWebアプリケーションの脆弱性（RCE）。そこを踏み台に攻撃者はクラスタ内へピボット（横展開）し、平文で通信していたマイクロサービス間のAPIをスニッフィング。他のテナントのデータベース接続文字列や、管理者権限を持つ内部APIトークンをごっそり抜き取っていった。

「ゼロトラスト」という言葉がバズワード化して久しいが、コンテナオーケストレーションの現場では、いまだに「境界の内側は安全」という古い城壁モデルの亡霊がうろついている。Kubernetesのデフォルト状態では、Pod間の通信はすべて暗号化なしの平文だ。

今回は、この悪夢のようなネットワーク盗聴となりすましを根絶やしにするための、Istio / Linkerdを用いたサービスメッシュによる相互TLS（mTLS）の設計と、現場で即座に使える実践的な構築手法を叩き込む。

—

1. なぜ「境界型防御」のKubernetesは破綻するのか？

多くのインフラエンジニアは、Kubernetesを導入した時点でセキュリティが担保されたと勘違いする。だが、考えてみてほしい。クラスタ内ネットワーク（Pod Network）において、デフォルトのCNIプラグイン（FlannelやCalicoのデフォルト設定など）は、パケットの暗号化を行っていない。

これはつまり、クラスタ内のどこか一つのPodが外部からの攻撃や内部不正によってコンプロマイズ（侵害）された瞬間、その同一ネットワーク上に流れるすべてのAPIリクエスト、JSONペイロード、Cookie、Authorizationヘッダーが、tcpdump や wireshark のような単純なツールで丸見えになるということだ。

さらに恐ろしいのは「なりすまし（IPスプーフィングやPod偽装）」だ。Kubernetesの標準機能だけでは、「どのPodがどのPodからの通信を許可すべきか」をアイデンティティベースで厳格に検証するのは難しい。ネットワークポリシー（NetworkPolicy）でIPやラベルベースの制御はできても、通信の主体が本当に正当なサービスであるかを暗号学的に証明することはできないのだ。

ここで登場するのが、サービスメッシュ（IstioやLinkerd）によるmTLS（相互TLS）である。

—

2. サービスメッシュによるmTLSのメカニズム

サービスメッシュを導入すると、アプリケーションコンテナのサイドカー（IstioならEnvoy、Linkerdならlinkerd2-proxy）としてプロキシがデプロイされる。
アプリケーション側は、暗号化や証明書の検証といった複雑なセキュリティロジックを一切意識する必要がない。すべてサイドカー間（Pod間）で自動的にハンドリングされる。

ここで重要なのは、単なる「通信の暗号化（TLS）」ではなく、「相互認証（Mutual TLS）」である点だ。
通信の送信側と受信側の双方が、Kubernetesのサービスアカウント（ServiceAccount）に紐づいたX.509証明書を提示し合い、お互いの身元を確認した上でセキュアなトンネルを確立する。これにより、攻撃者が仮に同じネットワークセグメントに侵入して偽のPodを立てたとしても、正しい証明書を持っていなければ通信を確立することは不可能になる。

—

3. 実践：Istioによる厳格なmTLSの設計と実装

口で言うだけではなく、実際にプロダクション環境で即座に適用できる設定を見ていこう。
Istioを導入し、クラスタ全体、あるいは特定のネームスペースに対して「厳格なmTLS（STRICTモード）」を強制するためのマニフェストだ。

クラスタワイドまたはネームスペース単位の PeerAuthentication 設定

まずは、トラフィックの暗号化と相互認証を強制するための PeerAuthentication リソースを定義する。ここでは、production ネームスペース配下のすべてのワークロードに対して、mTLSを強制（STRICT）する設定を記述している。

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production # 適用するネームスペースを指定
spec:
  mtls:
    mode: STRICT # PERMISSIVE（許容）ではなく必ずSTRICT（厳格）を指定すること

*セキュリティチーフの現場メモ:*
移行期には PERMISSIVE モード（平文とmTLSの両方を受け付ける）を使いがちだが、これは「暗号化されていない古い通信も通してしまう」という致命的な脆弱性を残すことになる。新規構築や移行完了後の環境では、必ず STRICT をデフォルトに設定しろ。

—

4. アプリケーション層での防衛：サイドカーを過信しない実装

インフラ側でmTLSを強制していても、アプリケーション層（PHPやPythonなど）の作り込みが甘ければ、結局はアプリケーションの脆弱性から足元をすくわれる。
ここでは、バックエンドのマイクロサービスと通信するPythonおよびPHPのサンプルコードを通じて、アプリケーション側が意識すべきセキュアな実装パターンを示す。

Python（requests）による内部API呼び出しのベストプラクティス

サービスメッシュ環境下では、サイドカープロキシがローカルループバック（localhost）上でTLS終端を行うため、アプリケーション自体は平文（http://）で通信して問題ないケースが多い。しかし、タイムアウト処理やエラーハンドリングを怠ると、DoSやスレッド枯渇の原因になる。

import requests
from requests.exceptions import RequestException

def call_internal_service(user_id: str) -> dict:
    """
    サービスメッシュ経由で内部の決済サービスを呼び出す関数。
    mTLSはサイドカー（Envoy）で担保されるため、URLはhttpで記述する。
    """
    # Istio等のサービスメッシュ環境ではKubernetesのサービス名でルーティング
    url = f"http://payment-service.production.svc.cluster.local/v1/charge"
    
    payload = {"user_id": user_id, "amount": 1000}
    headers = {"Content-Type": "application/json"}

    try:
        # 内部通信であっても必ずタイムアウトを設定する（無限待ちの防止）
        response = requests.post(url, json=payload, headers=headers, timeout=3.0)
        
        # HTTPステータスコードのチェック（4xx, 5xx系は例外を発生させる）
        response.raise_for_status()
        
        return response.json()

    except requests.exceptions.Timeout:
        # タイムアウト発生時のログ出力と適切なハンドリング
        print("[ERROR] 内部決済サービスへの接続がタイムアウトしました。")
        raise
    except requests.exceptions.RequestException as e:
        # その他のネットワークエラーやHTTPエラー
        print(f"[ERROR] 内部API呼び出しに失敗しました: {e}")
        raise

PHP（cURL）による内部API連携のセキュア実装

次に、PHP（Laravelやモダンなレガシーシステム）から内部APIを叩く際の実装例だ。ここでも厳格なタイムアウトとSSL/TLSオプションの確認（サイドカー経由のローカル通信における安全なハンドリング）が重要になる。

<?php

declare(strict_types=1);

/**
 * 内部のユーザー管理サービスへ安全にリクエストを送信する関数
 *
 * @param string $targetUserId
 * @return array|null
 * @throws \RuntimeException
 */
function fetchInternalUserData(string $targetUserId): ?array
{
    $url = "http://user-service.production.svc.cluster.local/api/users/{$targetUserId}";

    $ch = curl_init($url);

    // cURLのセキュリティと堅牢性の設定
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_TIMEOUT, 5); // 5秒でタイムアウト
    curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 2); // 接続確立は2秒以内
    curl_setopt($ch, CURLOPT_HTTPHEADER, [
        'Content-Type: application/json',
        'X-Internal-Request: true' // アプリケーション層での簡易的なバリデーション用ヘッダー
    ]);

    $response = curl_exec($ch);
    $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    $error = curl_error($ch);
    
    curl_close($ch);

    if ($error !== '') {
        // ネットワークレベルのエラー
        throw new \RuntimeException("内部API通信エラー: {$error}");
    }

    if ($httpCode !== 200) {
        // 予期せぬステータスコードのハンドリング
        throw new \RuntimeException("内部APIが異常レスポンスを返しました. Code: {$httpCode}");
    }

    $decodedData = json_decode($response, true);
    if (json_last_error() !== JSON_ERROR_NONE) {
        throw new \RuntimeException("JSONのパースに失敗しました。");
    }

    return $decodedData;
}

—

5. 認可ポリシー（AuthorizationPolicy）の適用：ゼロトラストの完成形

mTLSによって「通信が暗号化され、相手の身元が保証された」だけでは、セキュリティとしてはまだ半分だ。
「認証（Authentication）」ができたら、次は「認可（Authorization）」、すなわち「どのサービスがどのサービスへのアクセスを許可されているか」という最小権限の原則（The Principle of Least Privilege）を適用しなければならない。

以下のIstioの AuthorizationPolicy 設定例を見てほしい。ここでは、frontend というサービスアカウントを持つPodからのみ、backend-api へのアクセスを許可し、それ以外のすべてのサービスからのアクセスをデフォルトで拒否する設定を行っている。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: backend-api-access-control
  namespace: production
spec:
  selector:
    matchLabels:
      app: backend-api # このポリシーを適用するターゲットのPodラベル
  action: ALLOW
  rules:
  - from:
    - source:
        # frontend サービスアカウントからのアクセスのみを許可
        principals: ["cluster.local/ns/production/sa/frontend-service-account"]
    to:
    - operation:
        methods: ["POST", "GET"]
        paths: ["/api/v1/data/*"]

この設定を投入することで、万が一 frontend 以外の全く関係のないマイクロサービスがコンプロマイズされたとしても、そのサービスからは backend-api へ一歩も近づくことができなくなる。これが、私たちが現場で構築すべき真のセキュアなKubernetesアーキテクチャだ。

—

6. まとめ：セキュリティは「入れ物」ではなく「設計」で決まる

「Kubernetesを使っているから安心」「クラウドベンダーのマネージドサービスだから安全」――そんな幻想は今日で捨ててくれ。
インフラの便利さは、そのまま攻撃者にとっても「侵入しやすい高速道路」になり得る。

サービスメッシュによるmTLSの導入と、徹底した PeerAuthentication および AuthorizationPolicy の組み合わせは、もはや「あれば望ましい機能」ではなく、モダンなインフラエンジニアにとっての必須の教養であり、防衛ラインの要だ。

あなたの管理するクラスタのPod間通信は、今この瞬間も「丸見え」になっていないか？
ログを眺めて安心している暇があったら、今すぐネームスペースの PeerAuthentication の設定を確認しに行こう。現場からは以上だ。

スポンサーリンク

コメント

タイトルとURLをコピーしました