- Authors
- Name
- はじめに
- Kubernetes Network Policyの基礎
- Network Policy応用：Egress、CIDR、ポート制御
- Service Meshアーキテクチャ比較（Istio vs Cilium vs Calico）
- Istioベースのサービスメッシュ構築
- CiliumベースのeBPFサービスメッシュ
- mTLSとゼロトラストネットワーク
- 運用時の注意事項とトラブルシューティング
- 障害事例とリカバリー手順
- パフォーマンスベンチマークと選択ガイド
- おわりに
- 参考資料
はじめに
Kubernetesクラスターにおけるクラスター内のPod間通信は、デフォルトで**すべて許可（allow-all）**の状態です。同じクラスター内であれば、どのPodからでも他のPodに自由にアクセスできるということです。小規模な開発環境ではそれほど問題になりませんが、本番環境で数十、数百のマイクロサービスが動作している場合、これは深刻なセキュリティ上の脅威となります。
攻撃者が1つのPodを侵害すると、クラスター内のすべてのサービスへの横方向移動（lateral movement）が可能になるためです。これを防ぐには、Network Policyによるネットワークセグメンテーションと、Service MeshによるmTLS暗号化およびゼロトラストアーキテクチャが不可欠です。
この記事では、Kubernetes Network Policyの基礎から応用までを扱い、Istio、Cilium、Calicoの3つのソリューションのService Meshアーキテクチャを比較分析します。実際の運用で遭遇するトラブルシューティング事例やパフォーマンスベンチマークも含めて、皆さんの環境に最適な選択ができるようガイドします。
Kubernetes Network Policyの基礎
Network Policyとは？
Network PolicyはKubernetesネイティブのリソースで、Podレベルでインバウンド（Ingress）とアウトバウンド（Egress）のトラフィックを制御するファイアウォールルールです。ラベルセレクターに基づいて動作し、Podが再起動したりノード間を移動しても一貫したポリシーが適用されます。
重要な前提条件：Network Policyリソースを作成しても、それを実装するCNIプラグイン（Calico、Cilium、Antreaなど）がなければ、ポリシーは一切適用されません。デフォルトのkubenetやFlannelはNetwork Policyをサポートしていません。
Default Denyポリシー
すべてのネットワークセキュリティの出発点はDefault Denyポリシーです。まずすべてのトラフィックを遮断し、必要な通信のみを明示的に許可するホワイトリスト方式を適用します。
# default-deny-all.yaml
# ネームスペース内のすべてのPodのIngress/Egressトラフィックを遮断
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: production
spec:
podSelector: {} # 空のセレクター = ネームスペース内のすべてのPod
policyTypes:
- Ingress
- Egress
このポリシーが適用されると、productionネームスペースのすべてのPodはインバウンド/アウトバウンドのトラフィックが完全に遮断されます。DNS問い合わせも不可能になるため、必ずDNS許可ポリシーを併せて適用する必要があります。
# allow-dns.yaml
# kube-dns（CoreDNS）へのアクセスを許可するポリシー
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-dns
namespace: production
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
ports:
- protocol: UDP
port: 53
- protocol: TCP
port: 53
Pod間の特定通信の許可
Default Deny状態でフロントエンドがバックエンドAPIにアクセスできるようにする例です。
# allow-frontend-to-backend.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend-to-backend
namespace: production
spec:
podSelector:
matchLabels:
app: backend-api
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 8080
このポリシーは、app: frontendラベルを持つPodからapp: backend-api PodのTCPポート8080へのインバウンドトラフィックのみを許可します。
Network Policy応用：Egress、CIDR、ポート制御
Egressポリシーによる外部アクセス制御
マイクロサービスが外部APIやデータベースにアクセスする場合、Egressポリシーで許可対象を細かく制限できます。
# egress-external-api-and-db.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: backend-egress-policy
namespace: production
spec:
podSelector:
matchLabels:
app: backend-api
policyTypes:
- Egress
egress:
# 1. 同じネームスペースのRedisへのアクセスを許可
- to:
- podSelector:
matchLabels:
app: redis
ports:
- protocol: TCP
port: 6379
# 2. 外部PostgreSQL RDSへのアクセス（CIDRベース）
- to:
- ipBlock:
cidr: 10.100.0.0/16
ports:
- protocol: TCP
port: 5432
# 3. 外部HTTPS APIアクセスの許可
- to:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
ports:
- protocol: TCP
port: 443
# 4. DNSの許可
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
ports:
- protocol: UDP
port: 53
ネームスペース間通信の制御
マルチテナント環境ではネームスペース間の分離が必須です。特定のネームスペースからのみアクセスを許可するパターンです。
# cross-namespace-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-monitoring-access
namespace: production
spec:
podSelector:
matchLabels:
app: backend-api
policyTypes:
- Ingress
ingress:
# monitoringネームスペースのPrometheusのみメトリクススクレイピングを許可
- from:
- namespaceSelector:
matchLabels:
team: monitoring
podSelector:
matchLabels:
app: prometheus
ports:
- protocol: TCP
port: 9090
Network Policyの限界
Kubernetes標準のNetwork PolicyはL3/L4レベル（IP、ポート、プロトコル）の制御のみ可能です。以下のような要件は基本的なNetwork Policyでは対応できません：
- L7（HTTPパス、メソッド、ヘッダー）ベースのフィルタリング
- mTLS暗号化およびサービス認証
- トラフィックの可観測性（Observability）および分散トレーシング
- 高度なトラフィック管理（カナリアデプロイ、サーキットブレーカー、リトライ）
- FQDN（ドメイン）ベースのEgress制御
これらの高度な機能が必要な場合にService Meshが登場します。
Service Meshアーキテクチャ比較（Istio vs Cilium vs Calico）
3つの主要ソリューションのアーキテクチャと機能を比較します。
| 項目 | Istio（Ambient Mode） | Cilium Service Mesh | Calico（Enterprise） |
|---|---|---|---|
| データプレーン | ztunnel(L4) + Waypoint Proxy(L7) | eBPF(L3/L4) + ノード別Envoy(L7) | iptables/eBPF + Envoy(L7) |
| サイドカー | 不要（Ambient Mode） | 不要 | 選択的 |
| mTLS | 自動（HBONEプロトコル） | WireGuard/IPsec | WireGuard手動設定 |
| L7ポリシー | AuthorizationPolicy | CiliumNetworkPolicy | GlobalNetworkPolicy |
| 可観測性 | Kiali、Jaeger、Prometheus | Hubble（内蔵） | Calico Enterprise UI |
| 性能オーバーヘッド | 中（ztunnel経由） | 低（カーネルレベル） | 中 |
| CPU使用量 | 普通 | 30%少ない（L4基準） | 普通 |
| QPSパフォーマンス | 高い（低接続時に優秀） | 高い（高接続時に優秀） | 普通 |
| マルチクラスター | 対応（East-West Gateway） | Cluster Mesh対応 | Federation対応 |
| 学習曲線 | 高い | 中程度 | 中程度 |
| コミュニティ | 非常に大きい（CNCF Graduated） | 大きい（CNCF Graduated） | 大きい（Tigera主導） |
| Windowsノード | 非対応 | 非対応 | 対応 |
| 最適なユースケース | 大規模マルチクラスター、L7精密制御 | 高性能L4、eBPFベースの可観測性 | ハイブリッド環境、エンタープライズ規制準拠 |
アーキテクチャ選択基準
- 純粋なL3/L4ネットワークセキュリティのみ必要：Kubernetes標準Network Policy + Calico/Cilium CNI
- L7トラフィック管理 + mTLSが核心：Istio Ambient Mode
- 高性能 + カーネルレベルの可観測性：Cilium Service Mesh
- エンタープライズ規制準拠 + ハイブリッド：Calico Enterprise
Istioベースのサービスメッシュ構築
Istio Ambient Modeのインストール
Istio 1.24からAmbient Modeが正式GAになりました。従来のサイドカー方式と比較してCPU/メモリオーバーヘッドを90%以上削減しながら、mTLSとL7トラフィック管理を提供します。
# istioctlのインストール
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.24.2 sh -
export PATH="$HOME/istio-1.24.2/bin:$PATH"
# Ambientプロファイルでインストール
istioctl install --set profile=ambient --skip-confirmation
# インストール確認
kubectl get pods -n istio-system
# NAME READY STATUS RESTARTS AGE
# istiod-7b69f4b6c-xxxxx 1/1 Running 0 60s
# ztunnel-xxxxx 1/1 Running 0 60s
# istio-cni-node-xxxxx 1/1 Running 0 60s
# ネームスペースにAmbientモードを有効化
kubectl label namespace production istio.io/dataplane-mode=ambient
Waypoint Proxyのデプロイ（L7ポリシー用）
L4レベルのmTLSのみ必要であればztunnelだけで十分です。L7レベルの精密なトラフィック制御が必要な場合はWaypoint Proxyを追加デプロイします。
# Waypoint Proxyの作成
istioctl waypoint apply --namespace production --name backend-waypoint
# 特定サービスにWaypointを接続
kubectl label service backend-api \
istio.io/use-waypoint=backend-waypoint \
-n production
Istio AuthorizationPolicyの設定
IstioのL7ポリシーはAuthorizationPolicyを通じてHTTPメソッド、パス、ヘッダーレベルまで制御します。
# istio-auth-policy.yaml
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: backend-api-policy
namespace: production
spec:
targetRefs:
- kind: Service
group: ''
name: backend-api
action: ALLOW
rules:
- from:
- source:
principals:
- 'cluster.local/ns/production/sa/frontend'
to:
- operation:
methods: ['GET', 'POST']
paths: ['/api/v1/*']
- from:
- source:
principals:
- 'cluster.local/ns/monitoring/sa/prometheus'
to:
- operation:
methods: ['GET']
paths: ['/metrics']
このポリシーは、frontendサービスアカウントから/api/v1/パスへのGET、POSTのみを許可し、Prometheusから/metricsパスへのGETのみを許可します。その他のすべてのリクエストは403 Forbiddenで拒否されます。
CiliumベースのeBPFサービスメッシュ
Ciliumのインストールとサービスメッシュの有効化
CiliumはeBPFを活用してカーネルレベルでネットワーキングを処理します。サイドカープロキシなしでL4トラフィックを処理し、L7処理が必要な場合にのみノード別の共有Envoyプロキシを使用します。
# Cilium CLIのインストール
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
GOOS=$(go env GOOS)
GOARCH=$(go env GOARCH)
curl -L --fail --remote-name-all \
"https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-${GOOS}-${GOARCH}.tar.gz"
sudo tar xzvfC "cilium-${GOOS}-${GOARCH}.tar.gz" /usr/local/bin
# HelmでCiliumをインストール（Service Mesh + Hubble有効化）
helm repo add cilium https://helm.cilium.io/
helm repo update
helm install cilium cilium/cilium --version 1.17.0 \
--namespace kube-system \
--set kubeProxyReplacement=true \
--set hubble.enabled=true \
--set hubble.relay.enabled=true \
--set hubble.ui.enabled=true \
--set envoy.enabled=true \
--set encryption.enabled=true \
--set encryption.type=wireguard
# インストール確認
cilium status --wait
cilium connectivity test
CiliumNetworkPolicyによるL7ポリシーの適用
Ciliumは独自のCRDであるCiliumNetworkPolicyを通じて、HTTP、gRPC、KafkaなどのL7プロトコルレベルの精密なポリシーをサポートします。
# cilium-l7-policy.yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: backend-l7-policy
namespace: production
spec:
endpointSelector:
matchLabels:
app: backend-api
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: '8080'
protocol: TCP
rules:
http:
- method: 'GET'
path: '/api/v1/products'
- method: 'POST'
path: '/api/v1/orders'
- method: 'GET'
path: '/healthz'
- fromEndpoints:
- matchLabels:
app: prometheus
toPorts:
- ports:
- port: '9090'
protocol: TCP
rules:
http:
- method: 'GET'
path: '/metrics'
Hubbleを活用したネットワーク監視
CiliumのHubbleはeBPFベースですべてのネットワークフローをリアルタイムにモニタリングします。
# Hubble CLIインストール後に監視
hubble observe --namespace production --follow
# 特定Podのトラフィックのみフィルタリング
hubble observe --namespace production \
--to-label app=backend-api \
--verdict DROPPED
# HTTPリクエストの監視（L7）
hubble observe --namespace production \
--protocol http \
--http-status 5xx
# ネットワークフローの可視化（Hubble UI）
cilium hubble port-forward &
# ブラウザでhttp://localhost:12000にアクセス
Hubbleの出力例：
TIMESTAMP SOURCE DESTINATION TYPE VERDICT SUMMARY
Mar 14 10:23:01.123 production/frontend production/backend-api L7/HTTP FORWARDED GET /api/v1/products => 200
Mar 14 10:23:01.456 production/attacker production/backend-api L7/HTTP DROPPED POST /api/v1/admin => Policy denied
Mar 14 10:23:02.789 production/backend-api production/redis L4/TCP FORWARDED TCP 6379
mTLSとゼロトラストネットワーク
ゼロトラストとは？
ゼロトラスト（Zero Trust）は「何も信頼せず、すべてを検証する」というセキュリティモデルです。クラスター内部の通信も暗号化し、すべてのサービス間呼び出しでアイデンティティを検証します。Network Policyだけではトラフィックの暗号化ができないため、mTLS（mutual TLS）を提供するService Meshが必要です。
Istio Ambient ModeのmTLS
Istio Ambient Modeは**HBONE（HTTP-Based Overlay Network Environment）**プロトコルを使用して、すべてのトラフィックを自動的にmTLS暗号化します。ztunnelがノードレベルで証明書を管理し、各Podごとに固有のSPIFFEベースのワークロードIDを発行します。
# istio-peer-auth.yaml
# STRICTモード：mTLSでない平文トラフィックを拒否
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: strict-mtls
namespace: production
spec:
mtls:
mode: STRICT
STRICTモードを設定すると、そのネームスペースのすべてのサービスはmTLS接続のみを受け付けます。メッシュに含まれていないサービスからの平文リクエストはすべて拒否されます。
CiliumのWireGuardベース暗号化
Ciliumはカーネル内蔵のWireGuardを使用してノード間トラフィックを自動暗号化します。IstioのmTLSとは異なりアプリケーションレベルではなくカーネルレベルで動作するため、パフォーマンスオーバーヘッドが少なくなります。
# WireGuard暗号化状態の確認
cilium encrypt status
# 出力例：
# Encryption: Wireguard
# Keys in use: 2
# Errors: 0
# Interfaces: cilium_wg0
# 暗号化キー一覧の確認
cilium encrypt get
WireGuardとmTLSの違い：
- WireGuard：ノード間L3レベル暗号化、カーネルレベル処理、Pod個別IDなし
- mTLS（Istio）：サービス間L7レベル暗号化、SPIFFEベースのワークロードID、きめ細かな認可ポリシー
本番環境では、CiliumのWireGuardでノード間暗号化を適用し、さらにIstioのmTLSでワークロードレベルの認証まで実装する二重セキュリティ戦略を採用することもあります。
運用時の注意事項とトラブルシューティング
1. Network Policyの適用順序に注意
Network Policyは**和集合（additive）**方式で動作します。複数のポリシーが同一Podに適用される場合、許可ルールが合算されます。競合するポリシーがある場合、拒否ルールが優先されるのではなく、いずれか1つでも許可していればトラフィックが通過します。
# 特定Podに適用されているすべてのNetwork Policyの確認
kubectl get networkpolicy -n production -o wide
# Podラベルの確認（ポリシーセレクターのマッチング検証）
kubectl get pods -n production --show-labels
# Calicoを使用している場合のポリシーマッチング確認
calicoctl get networkpolicy -n production -o yaml
2. CNIプラグイン未インストール状態でのNetwork Policy無視
最もよくある間違いです。Network Policyリソースを作成しても、それを実装するCNIプラグインがなければポリシーは一切適用されません。
# CNIプラグインの確認
kubectl get pods -n kube-system | grep -E 'calico|cilium|antrea'
# Network Policyが実際に適用されているかの検証テスト
# 1. Default Denyの適用
kubectl apply -f default-deny-all.yaml
# 2. 通信テスト（遮断されるべき）
kubectl exec -n production deploy/frontend -- \
curl -s --connect-timeout 3 http://backend-api:8080/healthz
# タイムアウトが発生すればポリシーが正しく適用されている
3. DNS解決の失敗
Default Denyポリシー適用後にDNS許可を設定し忘れると、すべてのサービスディスカバリーが中断されます。
# DNS問題の診断
kubectl exec -n production deploy/frontend -- nslookup backend-api
# ;; connection timed out; no servers could be reached
# CoreDNS Podの確認
kubectl get pods -n kube-system -l k8s-app=kube-dns
# DNSポリシー適用後に再テスト
kubectl apply -f allow-dns.yaml
kubectl exec -n production deploy/frontend -- nslookup backend-api
# Server: 10.96.0.10
# Name: backend-api.production.svc.cluster.local
4. Istio ztunnel障害対応
ztunnelはノード別のDaemonSetとして実行され、障害時にそのノードのすべてのAmbient Meshトラフィックが中断されます。
# ztunnelの状態確認
kubectl get pods -n istio-system -l app=ztunnel
# ztunnelのログ確認（証明書問題の診断）
kubectl logs -n istio-system -l app=ztunnel --tail=50
# ztunnelの再起動
kubectl rollout restart daemonset/ztunnel -n istio-system
# IstiodとのxDS接続状態の確認
istioctl proxy-status
5. Cilium eBPFマップの容量超過
大規模クラスターではCiliumのeBPFマップのデフォルトサイズが不足する場合があります。
# eBPFマップの使用状況確認
cilium bpf ct list global | wc -l
cilium bpf policy get --all
# マップサイズの増加（Helm valuesの変更）
# bpf.ctGlobalTCPMax: 524288 （デフォルトより増加）
# bpf.ctGlobalAnyMax: 262144
# bpf.policyMapMax: 65536
# 変更の適用
helm upgrade cilium cilium/cilium \
--namespace kube-system \
--reuse-values \
--set bpf.ctGlobalTCPMax=524288
障害事例とリカバリー手順
事例1：誤ったEgressポリシーによる全サービス障害
状況：運用チームがセキュリティ強化のためにDefault Deny Egressを適用しましたが、DNS許可ポリシーを設定し忘れ、すべてのサービス間通信が中断しました。
症状：すべてのPodからサービス名でのアクセスが失敗。IP直接指定では通信可能。
リカバリー手順：
# 1. 即座に問題を確認
kubectl get networkpolicy -n production
# 2. DNS許可ポリシーの緊急適用
kubectl apply -f - <<'POLICY'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: emergency-allow-dns
namespace: production
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
ports:
- protocol: UDP
port: 53
- protocol: TCP
port: 53
POLICY
# 3. サービス復旧の確認
kubectl exec -n production deploy/frontend -- nslookup backend-api
教訓：Default Denyポリシーは必ずDNS許可ポリシーと一緒に適用する必要があります。ポリシー変更前に必ずステージング環境でテストし、ロールバック計画を準備してください。
事例2：Istioアップグレード中のmTLS不一致
状況：Istioバージョンアップグレードの過程で、旧バージョンのサイドカーと新バージョンのztunnel間でmTLSハンドシェイクが失敗しました。
症状：一部のサービス間で503エラーおよび「upstream connect error」メッセージが発生。
リカバリー手順：
# 1. mTLSモードを一時的にPERMISSIVEに変更（平文+mTLS両方許可）
kubectl apply -f - <<'POLICY'
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: permissive-during-upgrade
namespace: production
spec:
mtls:
mode: PERMISSIVE
POLICY
# 2. すべてのワークロードを再起動して最新プロキシを適用
kubectl rollout restart deployment -n production
# 3. すべてのPodが新バージョンに置き換わった後、STRICTを復元
kubectl rollout status deployment -n production --timeout=300s
kubectl apply -f - <<'POLICY'
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: strict-mtls
namespace: production
spec:
mtls:
mode: STRICT
POLICY
事例3：Cilium Agent再起動による瞬間的なトラフィックドロップ
状況：Cilium DaemonSetのアップデート中にノードのeBPFプログラムが一時的にアンロードされ、そのノードのPod間通信が数秒間中断しました。
リカバリーと予防：
# Rolling Update戦略で1ノードずつアップデート
helm upgrade cilium cilium/cilium \
--namespace kube-system \
--reuse-values \
--set upgradeCompatibility=1.16 \
--set rollOutCiliumPods=true
# PodDisruptionBudgetの確認
kubectl get pdb -n kube-system
# アップデート進行状況のモニタリング
kubectl rollout status daemonset/cilium -n kube-system --timeout=600s
パフォーマンスベンチマークと選択ガイド
実測ベンチマーク結果（2025年基準）
最近の大規模エンタープライズ環境での比較テスト結果を要約します。
| メトリック | Network Policy Only | Istio Ambient | Cilium Service Mesh |
|---|---|---|---|
| P99レイテンシ（ms） | 1.2 | 3.8 | 2.1 |
| QPS（リクエスト/秒） | 45,000 | 38,000 | 42,000 |
| QPS per Core | - | 2,178 | 1,815 |
| CPUオーバーヘッド | 基準 | +15% | +8% |
| メモリオーバーヘッド | 基準 | +120MB/ノード | +80MB/ノード |
| 低接続パフォーマンス | - | 優秀 | 普通 |
| 高接続パフォーマンス | - | 普通 | 優秀 |
注：IstioのQPS per Coreが高いのはL7処理能力が含まれた数値であり、CiliumのCPU測定にはカーネル内WireGuard暗号化コストが除外されている点を考慮する必要があります。
選択ガイドフローチャート
-
L3/L4ネットワーク分離のみ必要か？
- はい：Kubernetes Network Policy + CalicoまたはCilium CNIで十分
- いいえ：2番へ
-
L7トラフィック管理（カナリア、リトライ、サーキットブレーカー）が必要か？
- はい：Istio Ambient ModeまたはCilium + Envoy
- いいえ：3番へ
-
mTLSベースのゼロトラストが要件か？
- はい：Istio Ambient Mode（SPIFFEベースのワークロードID）
- いいえ：Cilium WireGuard暗号化でノード間暗号化
-
高性能 + カーネルレベルの可観測性が優先か？
- はい：Cilium Service Mesh + Hubble
- いいえ：Istio（より豊富なL7機能）
-
Windowsノード混用またはハイブリッド環境か？
- はい：Calico Enterprise
- いいえ：IstioまたはCilium
運用規模別の推奨事項
- 小規模クラスター（ノード10台以下）：Cilium CNI + 基本Network Policy。Service Mesh導入はオーバーヘッド対比メリットが少ない。
- 中規模クラスター（ノード10～100台）：Cilium Service MeshまたはIstio Ambient。L7要件に応じて選択。
- 大規模クラスター（ノード100台以上）：Istio Ambient Mode。成熟したマルチクラスターサポート、豊富なエコシステム、安定性。
- ハイブリッド/マルチクラウド：Calico EnterpriseまたはCilium Cluster Mesh。
おわりに
Kubernetesのネットワークセキュリティは、単にNetwork Policyを適用することを超えて、アプリケーションの特性とセキュリティ要件に合った包括的な戦略が必要です。
要点まとめ：
- Network Policyは基本中の基本：Default Denyから始めて、必要な通信のみを許可するホワイトリスト方式を必ず適用してください。DNS許可ポリシーを忘れないでください。
- Service Meshは必要な時に導入：mTLS、L7ポリシー、高度なトラフィック管理が実際に必要な時点で導入してください。不必要な複雑さはむしろ運用負担を増加させます。
- Istio vs Ciliumはトレードオフ：IstioはL7機能とエコシステムが豊富で、Ciliumはカーネルレベルの性能と可観測性が強みです。要件に合わせて選択してください。
- 段階的な導入が重要：Default Denyポリシーから始めて、Network Policyを十分に検証した後、必要に応じてService Meshを追加する段階的アプローチが最も安全です。
- 自動化とテスト：ポリシー変更は必ずCI/CDパイプラインを通じてステージングでまず検証し、ロールバック計画を常に準備してください。
ネットワークセキュリティは一度設定して終わりではありません。サービスが変化するにつれて、ポリシーも継続的にレビューし更新する必要があります。四半期ごとのポリシー監査を推奨し、HubbleやKialiなどの可観測性ツールを活用して実際のトラフィックパターンに基づいてポリシーを最適化してください。