Skip to main content

Kubernetes Network Policy によるゼロトラストセキュリティ実践ガイド

2026年5月27日by Kubo Team #Kubernetes #Network Policy #ゼロトラスト #セキュリティ #Cilium #Calico #ネットワーク

Kubernetes のデフォルト設定では、すべての Pod 間通信が無制限に許可されています。これは、1つのコンテナが侵害されるとクラスタ内のすべてのサービス（データベース、内部API、機密サービス）にネットワークアクセスが可能になることを意味します。

Kubernetes 公式ドキュメントが定義する Network Policy は、この問題に対するネイティブなソリューションです。本記事では、Default Deny からゼロトラストネットワークの完全実装までを、実際の YAML 設定例とともに解説します。

Kubo は月額48,000円〜のマネージド Kubernetes プラットフォームで、Network Policy のデフォルト適用を含むセキュリティ基盤を提供しています。

ゼロトラストモデルとは何か

ゼロトラストとは「何も信頼せず、すべての接続を明示的に許可する」セキュリティモデルです。Groundcover の解説によれば、Kubernetes においては「Pod は明確なポリシーがある場合にのみ通信できる」ことを意味します。

なぜ Kubernetes でゼロトラストが必要なのか

Atmosly のセキュリティガイドは、以下のリスクを指摘しています：

  • ラテラルムーブメント: 1つの Pod が侵害されると、同一クラスタ内の全サービスに到達可能
  • データ漏洩: データベース Pod への直接アクセスが可能
  • サプライチェーン攻撃: 侵害されたサードパーティコンテナからの内部ネットワーク探索

Network Policy は OSI レイヤー 3-4（IP/ポート）でトラフィックを制御し、これらのリスクを緩和します。

Captain.AI と Kubo では、AI ワーカー間の通信も Network Policy で最小限に制限されています。

Default Deny：ゼロトラストの第一歩

全 Ingress トラフィックを拒否

Kubernetes 公式ドキュメントに記載されている Default Deny ポリシー：

yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}      # 空セレクタ = namespace 内の全 Pod に適用
  policyTypes:
  - Ingress             # Ingress のみ拒否、Egress は許可

全 Egress トラフィックを拒否

yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Egress

全トラフィック（Ingress + Egress）を拒否

yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

重要: Default Deny を適用した後は、必要な通信を明示的に許可するポリシーを追加しなければ、アプリケーションが動作しなくなります。特に DNS（port 53）の Egress 許可 を忘れないでください。

実践的な Network Policy パターン

パターン1: フロントエンド → バックエンド → データベース

典型的な3層アーキテクチャでの Network Policy 設定例：

yaml
# バックエンド: フロントエンドからの Ingress のみ許可
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
---
# データベース: バックエンドからの Ingress のみ許可
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-database
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - protocol: TCP
      port: 5432

パターン2: namespace 間の通信制御

Red Hat のガイドで推奨されている、namespace を活用した分離：

yaml
# monitoring namespace からのメトリクス収集のみ許可
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: monitoring
    ports:
    - protocol: TCP
      port: 9090

パターン3: DNS と外部通信の許可

Daily.dev のベストプラクティスが強調する、DNS 許可の必須ルール：

yaml
# DNS Egress を全 Pod に許可（Default Deny Egress と併用必須）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

Cilium vs Calico：高度な CNI の選択

標準の Kubernetes Network Policy は L3-L4（IP/ポート）レベルの制御に限定されます。L7（HTTP/gRPC）レベルの制御やより高度な機能が必要な場合は、Cilium または Calico を検討しましょう。

Cilium

Cilium のゼロトラストセキュリティ実装によれば：

  • eBPF ベース: カーネルレベルで高性能にパケットを処理
  • L7 ポリシー: HTTP メソッド・パス・ヘッダーによるフィルタリング
  • DNS ベースの Egress 制御: FQDN で外部通信先を制限
  • Hubble: ネットワークフローのリアルタイム可視化
yaml
# Cilium L7 ポリシー例: GET リクエストのみ許可
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: l7-api-policy
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/v1/.*"

Calico

Calico のゼロトラストガイドによれば：

  • BGP ルーティング: 大規模ネットワークでの高いスケーラビリティ
  • GlobalNetworkPolicy: クラスタ全体に適用されるポリシー
  • ポリシーティア: 階層的なポリシー管理（セキュリティ > プラットフォーム > アプリケーション）
  • エンタープライズ対応: 成熟したコンプライアンス機能
比較項目CiliumCalico
データプレーンeBPFiptables / eBPF
L7 ポリシーネイティブ対応Envoy 連携が必要
可視化Hubble（組み込み）Calico Enterprise
スケーラビリティ高（eBPF）高（BGP）
学習コストやや高い中程度

段階的な導入戦略：Monitor-then-Enforce

2026年のベストプラクティスは、「Monitor-then-Enforce」ライフサイクルを推奨しています。

ステップ1: 現在のトラフィックフローを把握

Hubble（Cilium）や Calico Enterprise のフロー可視化で、実際の通信パターンを記録します。

ステップ2: Audit モードでポリシーをテスト

ステージング環境でポリシーを適用し、意図しないブロックがないか検証します。

ステップ3: 段階的に Enforce

namespace 単位で Default Deny を適用し、問題がないことを確認しながら本番環境に展開します。

ステップ4: 継続的な監視と改善

新しいサービスの追加や通信パターンの変更に合わせて、ポリシーを継続的に更新します。

まとめ：ゼロトラスト実装チェックリスト

Kubernetes Network Policy によるゼロトラストセキュリティは、以下の手順で実装できます：

  • 全 namespace に Default Deny（Ingress + Egress）を適用
  • DNS Egress を明示的に許可
  • アプリケーション間の必要最小限の通信を許可
  • namespace 間の通信を制御
  • 外部通信（Egress）を必要な宛先のみに制限
  • L7 レベルの制御が必要なら Cilium または Calico を導入
  • Monitor-then-Enforce の段階的導入を遵守

Kubo では、Network Policy のベースラインがプラットフォームレベルで適用されています。 月額48,000円〜で、セキュアな Kubernetes 環境をすぐに利用できます。Captain.AI との統合でAIワークロードのセキュリティも万全です。

ゼロトラストセキュリティの導入支援は お問い合わせ まで。

← Back to all posts