CiliumとeBPFで実現するKubernetesネットワークセキュリティ：L3/L4/L7ポリシーから暗号化まで

はじめに
eBPFとは？
- eBPF vs iptables 比較
Ciliumのインストール
- Helmでインストール
- インストールの確認
L3/L4ネットワークポリシー
- 基本的なCiliumNetworkPolicy
- ラベルベースの許可ポリシー
L7 HTTPポリシー — Ciliumの核心的な差別化ポイント
- L7 gRPCポリシー
DNSベースポリシー
WireGuard透過的暗号化
Hubbleネットワークオブザーバビリティ
- HubbleメトリクスをPrometheusで収集
実践シナリオ：マイクロサービスセキュリティ
CiliumClusterwideNetworkPolicy
トラブルシューティング
パフォーマンスベンチマーク
まとめ

はじめに

Kubernetesネットワークセキュリティの情勢が変わりつつあります。従来のiptablesベースのNetworkPolicyはL3/L4レベルの単純なIP/ポートフィルタリングしかできませんでしたが、CiliumはeBPFを活用してカーネルレベルでL7までの精密なネットワークポリシーを実現します。2026年2月にリリースされたCilium 1.19では、セキュリティ強化、暗号化の改善、大規模クラスタのスケーラビリティが大幅に向上しました。

この記事では、Ciliumをインストールし、実践的なネットワークポリシーをステップごとに構成していきます。

eBPFとは？

eBPF（extended Berkeley Packet Filter）は、Linuxカーネル内部でサンドボックス化されたプログラムを実行できる技術です。カーネルを変更することなく、ネットワーキング、セキュリティ、オブザーバビリティ機能を注入できます。

# eBPFサポートの確認
uname -r  # 5.10以上推奨
cat /boot/config-$(uname -r) | grep CONFIG_BPF
# CONFIG_BPF=y
# CONFIG_BPF_SYSCALL=y
# CONFIG_BPF_JIT=y

eBPF vs iptables 比較

項目	iptables	eBPF (Cilium)
処理場所	ユーザースペースルールチェーン	カーネル内で直接実行
L7サポート	不可	HTTP、gRPC、Kafkaなど
パフォーマンス	ルール数に比例して低下	O(1)ハッシュマップルックアップ
オブザーバビリティ	別途ツールが必要	Hubble内蔵
暗号化	非対応	WireGuard/IPsec

Ciliumのインストール

Helmでインストール

# Helm repoの追加
helm repo add cilium https://helm.cilium.io/
helm repo update

# Ciliumのインストール（kube-proxy置き換えモード）
helm install cilium cilium/cilium --version 1.19.0 \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=<API_SERVER_IP> \
  --set k8sServicePort=6443 \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true \
  --set encryption.enabled=true \
  --set encryption.type=wireguard

インストールの確認

# Ciliumのステータス確認
cilium status --wait

# 接続テスト
cilium connectivity test

出力例：

    /¯¯\
 /¯¯\__/¯¯\    Cilium:             OK
 \__/¯¯\__/    Operator:           OK
 /¯¯\__/¯¯\    Envoy DaemonSet:    OK
 \__/¯¯\__/    Hubble Relay:       OK
    \__/        ClusterMesh:        disabled

Deployment             cilium-operator    Desired: 1, Ready: 1/1
DaemonSet              cilium             Desired: 3, Ready: 3/3

L3/L4ネットワークポリシー

基本的なCiliumNetworkPolicy

標準のKubernetes NetworkPolicyとは異なり、CiliumNetworkPolicyはより細かい制御が可能です。

# deny-all.yaml - すべてのトラフィックを遮断（デフォルト拒否ポリシー）
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  endpointSelector: {} # すべてのPodに適用
  ingress:
    - {} # 空のルール = 何も許可しない

kubectl apply -f deny-all.yaml

# テスト：別のNamespaceからアクセスを試行
kubectl run test --rm -it --image=curlimages/curl -- \
  curl -s --connect-timeout 3 http://app.production.svc.cluster.local
# curl: (28) Connection timed out

ラベルベースの許可ポリシー

# allow-frontend-to-backend.yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: '8080'
              protocol: TCP

L7 HTTPポリシー — Ciliumの核心的な差別化ポイント

ここからがCiliumの真価を発揮するところです。HTTPパス、メソッド、ヘッダーまでフィルタリングできます。

# l7-http-policy.yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-l7-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: api-server
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: '8080'
              protocol: TCP
          rules:
            http:
              # GET /api/products のみ許可
              - method: GET
                path: '/api/products'
              # POST /api/orders のみ許可
              - method: POST
                path: '/api/orders'
              # GET /api/users/* パターンを許可
              - method: GET
                path: '/api/users/[0-9]+'

L7 gRPCポリシー

# l7-grpc-policy.yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: grpc-l7-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: grpc-server
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: grpc-client
      toPorts:
        - ports:
            - port: '50051'
              protocol: TCP
          rules:
            http:
              - method: POST
                path: '/mypackage.MyService/GetItems'
              - method: POST
                path: '/mypackage.MyService/CreateItem'

DNSベースポリシー

外部サービスへのアクセスをFQDNで制御できます。

# dns-policy.yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-external-apis
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: backend
  egress:
    # 特定の外部APIのみ許可
    - toFQDNs:
        - matchName: 'api.stripe.com'
        - matchName: 'api.github.com'
        - matchPattern: '*.amazonaws.com'
      toPorts:
        - ports:
            - port: '443'
              protocol: TCP
    # DNSルックアップの許可（必須！）
    - toEndpoints:
        - matchLabels:
            k8s:io.kubernetes.pod.namespace: kube-system
            k8s-app: kube-dns
      toPorts:
        - ports:
            - port: '53'
              protocol: UDP
          rules:
            dns:
              - matchPattern: '*'

# DNSポリシーのテスト
kubectl exec -n production deploy/backend -- \
  curl -s https://api.stripe.com/v1/charges  # 成功
kubectl exec -n production deploy/backend -- \
  curl -s https://evil-site.com  # ブロック

WireGuard透過的暗号化

Cilium 1.19では、WireGuardベースのノード間暗号化がさらに安定しました。

# 暗号化ステータスの確認
cilium encrypt status

# Helm valuesでWireGuardを有効化
# values-encryption.yaml
encryption:
  enabled: true
  type: wireguard
  wireguard:
    userspaceFallback: false
  nodeEncryption: true # ノード間のすべてのトラフィックを暗号化

# 暗号化の検証 - tcpdumpでパケットを検査
kubectl exec -n kube-system ds/cilium -- \
  tcpdump -i cilium_wg0 -c 5 2>&1 | head -10

# WireGuardインターフェースで暗号化トラフィックを確認
kubectl exec -n kube-system ds/cilium -- \
  cilium-dbg encrypt status

Hubbleネットワークオブザーバビリティ

HubbleはCilium内蔵のオブザーバビリティツールで、すべてのネットワークフローをリアルタイムでモニタリングします。

# Hubble CLIのインストール
HUBBLE_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/hubble/master/stable.txt)
curl -L --remote-name-all \
  https://github.com/cilium/hubble/releases/download/$HUBBLE_VERSION/hubble-linux-amd64.tar.gz
tar xzvf hubble-linux-amd64.tar.gz
sudo mv hubble /usr/local/bin/

# Hubbleポートフォワーディング
cilium hubble port-forward &

# リアルタイムフロー監視
hubble observe --namespace production

# ドロップされたトラフィックのみフィルタ
hubble observe --namespace production --verdict DROPPED

# HTTPリクエストのみフィルタ
hubble observe --namespace production --protocol http

# 特定Podのトラフィック
hubble observe --to-pod production/backend-xxx --type l7

HubbleメトリクスをPrometheusで収集

# values-hubble-metrics.yaml
hubble:
  metrics:
    enabled:
      - dns
      - drop
      - tcp
      - flow
      - icmp
      - http
    serviceMonitor:
      enabled: true

# メトリクスの確認
curl -s http://localhost:9965/metrics | grep hubble

実践シナリオ：マイクロサービスセキュリティ

アーキテクチャ全体にCiliumポリシーを適用する例です。

# microservice-policies.yaml
---
# 1. Frontend -> API Gatewayのみ許可
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: frontend-egress
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      tier: frontend
  egress:
    - toEndpoints:
        - matchLabels:
            tier: api-gateway
      toPorts:
        - ports:
            - port: '8080'
---
# 2. API Gateway -> Backendサービス（L7制御）
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-gateway-egress
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      tier: api-gateway
  egress:
    - toEndpoints:
        - matchLabels:
            tier: backend
            service: user-service
      toPorts:
        - ports:
            - port: '8081'
          rules:
            http:
              - method: GET
                path: '/users/.*'
              - method: POST
                path: '/users'
    - toEndpoints:
        - matchLabels:
            tier: backend
            service: order-service
      toPorts:
        - ports:
            - port: '8082'
          rules:
            http:
              - method: GET
                path: '/orders/.*'
              - method: POST
                path: '/orders'
---
# 3. Backend -> Database（ポート制限）
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: backend-to-db
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      tier: backend
  egress:
    - toEndpoints:
        - matchLabels:
            tier: database
      toPorts:
        - ports:
            - port: '5432'
              protocol: TCP

CiliumClusterwideNetworkPolicy

クラスタ全体に適用されるポリシーです。

# cluster-wide-deny-external.yaml
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: deny-external-by-default
spec:
  endpointSelector:
    matchExpressions:
      - key: io.kubernetes.pod.namespace
        operator: NotIn
        values:
          - kube-system
          - ingress-nginx
  egress:
    # クラスタ内部のみ許可
    - toEntities:
        - cluster
    # DNSは許可
    - toEndpoints:
        - matchLabels:
            k8s:io.kubernetes.pod.namespace: kube-system
      toPorts:
        - ports:
            - port: '53'
              protocol: UDP

トラブルシューティング

# ポリシー適用状態の確認
kubectl get cnp -A
kubectl get ccnp

# 特定Podのポリシーステータス
kubectl exec -n kube-system ds/cilium -- \
  cilium-dbg endpoint list

# ポリシーデバッグ
kubectl exec -n kube-system ds/cilium -- \
  cilium-dbg policy get -n production

# BPFマップステータスの確認
kubectl exec -n kube-system ds/cilium -- \
  cilium-dbg bpf policy get --all

# Identityの確認
kubectl exec -n kube-system ds/cilium -- \
  cilium-dbg identity list

パフォーマンスベンチマーク

# iperf3でネットワークパフォーマンスを測定
# サーバーPod
kubectl run iperf-server --image=networkstatic/iperf3 -- -s

# クライアントからテスト
kubectl run iperf-client --rm -it --image=networkstatic/iperf3 -- \
  -c iperf-server -t 30 -P 4

# 一般的な結果：
# iptables CNI: 約9.2 Gbps
# Cilium eBPF:  約9.8 Gbps（約6-7%向上）
# Cilium + WireGuard: 約8.5 Gbps

まとめ

機能	従来のNetworkPolicy	CiliumNetworkPolicy
L3/L4フィルタリング	O	O
L7 HTTPフィルタリング	X	O
L7 gRPCフィルタリング	X	O
DNSベースポリシー	X	O
暗号化	X	WireGuard/IPsec
オブザーバビリティ	X	Hubble内蔵
クラスタ全体ポリシー	X	CCNP
パフォーマンス	iptables依存	eBPF最適化

Ciliumは単なるCNIを超え、Kubernetesネットワークセキュリティプラットフォームとしての地位を確立しました。特にL7ポリシーとHubbleオブザーバビリティは、マイクロサービス環境において必須の機能です。

クイズ：CiliumとeBPFの理解度チェック（7問）

Q1. eBPFがiptablesよりパフォーマンスが優れている主な理由は？

カーネル内で直接実行され、ハッシュマップベースのO(1)ルックアップにより、ルール数に関係なく一定のパフォーマンスを維持します。

Q2. CiliumNetworkPolicyでL7 HTTPポリシーを適用するにはどのフィールドを使用しますか？

toPorts.rules.httpフィールドでmethod、pathなどを指定します。

Q3. DNSベースのegressポリシーを設定する際、必ず一緒に許可しなければならないものは？

kube-dnsへのUDP 53ポートトラフィックを許可する必要があります。DNS解決ができないとFQDNポリシーが機能しません。

Q4. Ciliumがサポートする透過的暗号化方式の2つは？

WireGuardとIPsecです。Cilium 1.19ではWireGuardが推奨されています。

Q5. Hubbleでドロップされたトラフィックのみを表示するにはどのオプションを使いますか？

hubble observe --verdict DROPPED

Q6. CiliumClusterwideNetworkPolicy（CCNP）とCiliumNetworkPolicy（CNP）の違いは？

CCNPはクラスタ全体に適用されNamespaceを持ちません。CNPは特定のNamespaceにのみ適用されます。

Q7. Ciliumをkube-proxy置き換えモードでインストールするメリットは？

iptablesルールチェーンが排除されてサービスルーティングのパフォーマンスが向上し、大規模クラスタでルール数の増加に伴うパフォーマンス低下がなくなります。