境界防御の終焉と「ゼロトラスト・ネットワーキング」の現在地
「ファイアウォールで囲えば安全」という時代は、コンテナ化の波と共に物理的に崩壊した。クラウドネイティブな環境において、境界とはもはや静的な壁ではなく、Podという動的なエンティティが常に移動・増殖する複雑な網目状の構造体に他ならない。
多くのエンジニアが陥る罠は、KubernetesのNamespaceを信頼の境界と誤認することだ。Default Namespaceに配置されたPodが、横方向（East-West）の移動によって、いとも簡単に権限昇格やサービス破壊を引き起こす。今回は、Ciliumを主軸としたマイクロセグメンテーションの深淵に切り込む。
なぜデフォルト拒否（Default Deny）こそが唯一の解なのか
Kubernetesのデフォルト設定では、全てのPodは相互に通信可能だ。これは「開発の利便性」を優先した結果だが、セキュリティの観点では「全ポートを開放した無防備なネットワーク」と同義である。
攻撃者の視点に立てば、一度クラスタ内に足掛かり（Initial Access）を得れば、あとはARPスプーフィングやDNSリバインディング、あるいは単純なTCPスキャンで全貌を把握できる。この「偵察」フェースを物理的に遮断するのが、Network Policyによるホワイトリスト戦略だ。
最小権限原則をコードで実装する
まずは、Namespace単位で「全てのインバウンド・アウトバウンド通信を拒否」するポリシーを適用する。これが全ての防御の起点となる。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: sensitive-app
spec:
podSelector: {} # セレクターを空にすることで、Namespace内の全Podを対象とする
policyTypes:
- Ingress
- Egress
この設定を適用した瞬間、DNS解決すら不可能になる。この泥臭い「繋がらない」を一つずつ紐解くプロセスこそが、アプリケーションの通信フローを正しく設計する唯一の道だ。
CiliumとeBPFがもたらす「L7可視化」のパラダイムシフト
従来のiptablesベースのネットワークポリシーは、iptablesのルール数が膨大になるとパフォーマンスが線形に低下する。また、L3/L4レベルのIP/Port制限では、HTTP/gRPCのパスやメソッド単位の制御は不可能だった。
ここで登場するのがeBPF（extended Berkeley Packet Filter）だ。Ciliumはカーネル空間でパケットを直接フックし、iptablesを通さずに処理を行う。
L7ポリシーによる「プロトコル単位」の防御
例えば、攻撃者が特定のマイクロサービスに対して、認可されていないパス（例: `/admin/dump_db`）を叩こうとした場合、L3/L4レベルでは防げない。しかし、CiliumのL7ポリシーなら可能だ。
apiVersion: “cilium.io/v2”
kind: CiliumNetworkPolicy
metadata:
name: “l7-rule-secure-api”
spec:
endpointSelector:
matchLabels:
app: backend-api
ingress:
- fromEndpoints:
- matchLabels:
app: frontend-web
toPorts:
- ports:
- port: “8080”
protocol: TCP
rules:
http:
- method: “GET”
path: “/api/v1/public/.” # 正規表現で認可されたパスのみを許可
このアプローチは、アプリケーション層の脆弱性（例: SSRFや不適切な認証）に対する最後のガードレイルとして機能する。
現代のセキュリティアーキテクトが直面する盲点
どれだけ精緻なネットワークポリシーを組んでも、以下の点は多くの現場で見落とされている。
1. DNSトラフィックの制御: 多くのNetwork PolicyがDNSのUDP 53番ポートを許可し忘れている。あるいは、攻撃者が内部DNSを悪用して外部へのExfiltration（データ流出）を試みるケースがある。Ciliumの`fqdn`ポリシーを用いた、ドメイン単位のホワイトリスト化を推奨する。
2. 耐量子暗号（PQC）と通信の断片化: 今後、TLS 1.3の暗号スイートが耐量子暗号へ移行する際、パケットサイズは肥大化する。MTUサイズを考慮しない過度なフィルタリングは、パケットドロップによるパフォーマンス劣化を招く。低レイヤのMTU解析と、ポリシー設計の整合性は常にセットで評価すべきだ。
3. 生成AIに対するガードレイル: プロンプトインジェクションはアプリケーションロジックの領域だが、その攻撃コードが外部からインジェクションされる経路はネットワークにある。ネットワークポリシーで外部の不正なAPIエンドポイントへのEgressを完全に遮断し、AIの推論サーバーが「通信できる先」を厳格に制限することで、被害を局所化せよ。
監査の観点から：ポリシーは「生きて」いるか
セキュリティポリシーは「設定して終わり」ではない。GitOps（ArgoCDやFlux）で管理し、ポリシーの変更履歴と、実際の通信フローの差分を監視し続ける必要がある。
インシデントハンドリングの現場では、「なぜその通信が許可されていたのか？」という問いに即答できる環境が、勝敗を分ける。Ciliumの`hubble`を使用して、リアルタイムのフローログを可視化し、異常な通信パターンを検知するSIEMとの連携フローを構築すること。
最後に一つだけ助言を贈る。セキュリティとは「完璧な防壁」を築くことではない。「攻撃者が侵入した際、次にどこへも行けないようにし、なおかつその足跡を確実に記録し続けること」だ。Kubernetesのネットワークポリシーは、そのための最も強力な武器となる。
自身のクラスタを守るのは、マニュアルを読み込んだAIではなく、パケットの呼吸を聞き分けられるあなた自身であるべきだ。
コメント