【Cilium 1.19】WireGuard Strictモードで実現するKubernetesノード間通信の完全暗号化

Container & Orchestration

この記事の概要

Cilium 1.19（2026年2月リリース、10周年記念版）でWireGuard/IPsecの「Strictモード」が導入されました。従来のベストエフォート型とは異なり、Strictモードは暗号化されていないノード間トラフィックを即座にドロップします。金融・公共機関などゼロトラストが求められる環境での採用が一気に現実的になった変更です。本記事ではStrictモードの仕組み・設定方法・移行手順を実務目線で解説します。

暗号化を「ベストエフォート」から「強制」に変える一行設定

Cilium 1.19の最大のセキュリティ強化は、WireGuardとIPsecのStrictモードです。

デフォルトのCilium暗号化は「透過的暗号化（Transparent Encryption）」と呼ばれ、正常なノード間通信は暗号化される。しかし従来の設定では、暗号化に失敗したトラフィックが平文のまま通過してしまうリスクがありました。ノードの再起動直後やWireGuardトンネルの再確立中など、一時的に暗号化が外れたパケットが到達してしまうケースです。

Strictモードを有効にすると、この動作が根本から変わります。

暗号化に失敗したパケット → 遮断（DROP）

「暗号化しようとするが失敗したら通す」ではなく、「暗号化されていなければ通さない」という強い保証を得られる。これはゼロトラストネットワークが前提とする「デフォルト拒否」に沿った設計です。

なぜデフォルト設定のままでは本番ゼロトラストは達成できないのか

Kubernetesクラスター内通信の暗号化が難しい理由

クラスター内のPod間通信は、一般的にプライベートネットワーク上を流れる。しかし、以下のシナリオでは内部通信が平文で傍受されうる。

  • マルチテナントクラスター：複数チームが同一クラスターを共有している場合、悪意あるPodが同一ノード上の他Pod通信を傍受できる
  • コンプライアンス要件：PCI-DSS、HIPAA、FISCなどの規制では「保存データだけでなく転送データも暗号化」が求められる
  • クラウドプロバイダーの限界：EKS/GKE/AKSのノード間通信は物理的にはプロバイダーの管理下だが、監査証跡として「E2E暗号化」の証明が必要になる場面がある

「暗号化している”つもり”」の罠

Redditのk8sコミュニティでは、以前から「CiliumのWireGuardを有効にしたが、本当に全パケットが暗号化されているか確認できない」という声がありました。これは決して杞憂ではなく、旧来のベストエフォートモードには以下の抜け穴がありました。

  1. ノード起動時のWireGuardトンネル確立前に平文パケットが流れる
  2. IPsecキーのローテーション中に一時的に平文通信が発生する
  3. クラスターメッシュ接続先のノードキーが更新されるタイムラグで平文通信が生じる

Strictモードはこれらすべての「一時的な平文通信」を根絶します。

>cilium1: パケット送信
cilium1->>cilium1: WireGuardトンネル確認
alt トンネル未確立
cilium1->>cilium1: DROP（平文送信しない）
else トンネル確立済み
cilium1->>cilium2: 暗号化済みUDP 51871
cilium2->>PodB: 復号後転送
end
–>

Cilium WireGuard Strictモードを実際に設定する

前提条件

  • Kubernetes 1.29以上
  • Linuxカーネル 5.6以上（WireGuardカーネルモジュール CONFIG_WIREGUARD=m が必要）
  • Cilium 1.19.x

カーネルのWireGuardサポートは以下で確認できる。

# WireGuardモジュールの確認
modinfo wireguard 2>/dev/null && echo "WireGuard対応" || echo "WireGuard未対応"

# Linuxカーネルバージョン確認
uname -r

実装例・コード例

新規インストール時（Helm）

helm install cilium cilium/cilium --version 1.19.4 \
  --namespace kube-system \
  --set encryption.enabled=true \
  --set encryption.type=wireguard \
  --set encryption.strictMode.enabled=true \
  --set encryption.nodeEncryption=true

既存クラスターへの適用（Helm upgrade）

既存クラスターへの適用は段階的に行うこと。いきなりStrictモードを有効にするとトンネル確立前のトラフィックがドロップされ、一時的な通信断が発生します。推奨手順は以下のとおりです。

# Step 1: まず通常のWireGuard暗号化を有効化（Strictなし）
helm upgrade cilium cilium/cilium --version 1.19.4 \
  --namespace kube-system \
  --reuse-values \
  --set encryption.enabled=true \
  --set encryption.type=wireguard

# WireGuardトンネルが全ノードで確立されるまで待機（数分）
kubectl -n kube-system rollout status daemonset/cilium

# Step 2: 全ノードのWireGuardトンネル確立を確認
kubectl -n kube-system exec ds/cilium -- cilium-dbg status | grep Encryption

# 出力例（全ノードがPeersとして表示されていれば成功）
# Encryption: Wireguard [cilium_wg0 (Pubkey: <...>, Port: 51871, Peers: 3)]

# Step 3: Strictモードを有効化
helm upgrade cilium cilium/cilium --version 1.19.4 \
  --namespace kube-system \
  --reuse-values \
  --set encryption.strictMode.enabled=true

設定確認コマンド

# WireGuardトンネルの状態確認
kubectl -n kube-system exec ds/cilium -- \
  cilium-dbg debuginfo --output json | jq .encryption

# 暗号化済みトラフィックの確認（tcpdumpによる検証）
kubectl -n kube-system exec -ti ds/cilium -- bash
apt-get update && apt-get -y install tcpdump
# cilium_wg0インターフェースでパケットを確認（ここに流れていれば暗号化済み）
tcpdump -n -i cilium_wg0

Hubbleで暗号化フィルタリング

Cilium 1.19からHubble CLIで暗号化ステータスによるフィルタリングができるようになりました。

# 暗号化されていないトラフィックを検出
hubble observe --verdict DROPPED --not-encrypted

# 暗号化済みトラフィックのみ表示
hubble observe --encrypted

EKSでのWireGuard利用時の注意点

AWS EKSでCNIチェーニング（aws-vpc-cni + Cilium）を使う場合、MTU設定が必要。

# EKS用：aws-cni chaining時のMTU設定
helm upgrade cilium cilium/cilium --version 1.19.4 \
  --namespace kube-system \
  --reuse-values \
  --set cni.enableRouteMTUForCNIChaining=true \
  --set encryption.enabled=true \
  --set encryption.type=wireguard \
  --set encryption.strictMode.enabled=true

WireGuardトンネルはUDP 51871 ポートを使用します。EKSのセキュリティグループで以下を許可してください。

# セキュリティグループルール（ワーカーノード間）
Protocol: UDP
Port: 51871
Source: ノードのCIDRブロック（例: 10.0.0.0/16）

実務での活用シナリオ

シナリオ①：マルチテナントEKSクラスター

複数プロダクトチームが同一EKSクラスターを共有するケースでは、Ciliumネットワークポリシーによる論理分離に加え、WireGuard Strictモードでノード間通信を物理レベルで暗号化します。これにより「名前空間分離はしているが実は暗号化されていない」状態を解消できる。

シナリオ②：金融系ワークロードのコンプライアンス対応

「転送データの暗号化」を監査で証明する際、cilium-dbg statusやHubbleのログを証跡として提出できる。Strictモードにより「暗号化の保証」を文書化しやすくなります。

シナリオ③：クラスターメッシュでの複数クラスター連携

Cilium Cluster Mesh利用時もWireGuard暗号化は有効。1.19からはクラスターメッシュ接続でもclustermesh-apiserverが自動的に公開鍵を交換し、クラスター間通信も暗号化される。ただし参加する全クラスターでWireGuardを有効化している必要がある（混在モード非対応）。

今すぐStrictモードに移行するための3つのステップ

Cilium WireGuard Strictモードへの移行は、以下の手順で安全に実施できる。

Step 1：現在の暗号化状態の棚卸し

まずcilium-dbg statusで現在の暗号化設定を確認し、全ノードでWireGuardトンネルが確立されているかチェックします。Hubble UIがあれば、暗号化されていないFlowがないか確認しておく。

Step 2：段階的な有効化（Strict前にWireGuard通常モードで安定確認）

ノード間でWireGuardトンネルが確立されるには数分かかる。encryption.enabled=trueのみでまず稼働させ、全ノードでPeersカウントが正常になったことを確認してからStrictモードを追加します。本番環境ではメンテナンスウィンドウ内での実施を推奨。

Step 3：ファイアウォール・SGルールの確認

WireGuardはUDP 51871を使用します。オンプレK8s環境ではkube-firewallやiptables、クラウド環境ではセキュリティグループ/ネットワークACLでこのポートが許可されているか確認してください。見落としがちだが、Strictモードを有効にした後にこのポートが塞がれていると全ノード間通信が遮断されます。

まとめ

Cilium 1.19のWireGuard Strictモードは、「暗号化しているつもり」から「暗号化を保証する」への大きな一歩です。設定自体はencryption.strictMode.enabled=trueの一行追加だが、既存クラスターへの適用は段階的に行うことで無停止での移行が可能。

ゼロトラストセキュリティを推進しているチーム、または金融・医療など規制業種のKubernetes運用チームには、今すぐ検討する価値があります。

Ciliumは今や本番Kubernetesの60%超で採用され、Google・Microsoft・AWSの管理型K8sサービスでも採用されています。次のバージョンCilium 1.20では、ZtunnelによるサイドカーレスmTLSが本格化する見込み。引き続き注目したい。

参考リンク

コメント