Cilium + Kubernetes によるドメインベース通信制御構成の検討

1. 背景

以前、Docker コンテナの外向き通信制御について調査を行い、最終的には DOCKER-USER + ipset による IP allowlist 制御へ到達した。

しかし、この方式には以下の課題が残っていた。

  • 許可対象はドメインで管理したい
  • CDN による IP 変動への追従が必要
  • DNS 解決結果の管理が必要
  • IP ベース制御では意図しない到達先が残る可能性がある

また、近年は AI エージェントの利用が増え、実行環境に対するネットワーク制御の重要性も高まっている。

そこで今回は、Docker 単体での制御ではなく、Kubernetes + Cilium を利用した構成を検討してみた。

なお、本記事は構成案の整理が目的であり、ベストプラクティスを示すものではない。

2. やりたいこと

  • 特定ワークロードのみ外部通信を許可する
  • 許可先はドメイン単位で管理する
  • 未許可通信は拒否する
  • 通信状況を可視化する
  • Infrastructure as Code で管理する

3. Docker 単体構成で感じた限界

Docker 単体でも iptables、nftables、DOCKER-USER、ipset、Proxy による制御は可能である。

しかし、ドメイン単位の制御を行おうとすると設計が急激に複雑になる。

4. Cilium に興味を持った理由

Cilium には FQDN ベースの Egress 制御機能が存在する。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
spec:
  egress:
    - toFQDNs:
        - matchName: api.openai.com

これにより IP アドレスではなくドメイン単位で通信制御を行える。

5. なぜ Kubernetes を採用するのか

Cilium は Kubernetes 上で利用するのが一般的であり、NetworkPolicy、Service、Namespace、Hubble などの仕組みを活用できる。

6. 現時点の構成案

Host Linux → KVM → minikube → Cilium → Application Pod

7. 今後の調査

  • FQDN Policy の実運用性
  • DNS キャッシュとの関係
  • CDN 利用サービスとの相性
  • Hubble による通信可視化
  • Calico との比較

また、AI エージェント向けサンドボックス環境との比較も行いたい。

対象例:

  • OpenAI Codex
  • OpenHands
  • Devin
  • Cline
  • Roo Code
  • Anthropic Computer Use

本記事の最終目標は、AI エージェント実行基盤として成立するネットワーク制御方式を理解することである。

Back to home