Kubernetesの「デフォルト全許可」は悪夢の始まりだ：マイクロセグメンテーションで守るクラスターの現実
現場の諸君、今日も元気にKubernetes（K8s）を運用しているか？
多くのエンジニアが陥る罠がある。「とりあえず動くから」といって、デフォルトのままPodをデプロイし、クラスター内の全Podが互いに通信できる状態を放置していることだ。これは、家中のドアをすべて開放して、「泥棒が入らないように祈る」のと変わらない。
もし、君たちが開発したWebアプリケーションのPHPファイルにLFI（ローカルファイルインクルード）の脆弱性があり、攻撃者がRCE（リモートコード実行）に成功したとしよう。ネットワークポリシーがなければ、攻撃者はそのPodを踏み台にして、クラスター内の他のマイクロサービスへ横展開（Lateral Movement）し、最終的にデータベースや秘匿情報が格納されたPodに到達する。
今日は、CiliumなどのCNIを活用した「ホワイトリスト形式」のネットワーク制御について、現場で使える実装を叩き込む。
—
1. 攻撃者の視点：Pod間通信の盲点
攻撃者は、侵害したPod内でまず最初に `curl` や `nmap` を叩き、クラスター内のIP範囲をスキャンする。彼らはKubernetes DNSを逆引きし、`db-service.production.svc.cluster.local` のようなエンドポイントを特定する。
ネットワークポリシーがなければ、攻撃者のコードは以下のコマンドで君たちの宝物を盗み出すだろう。
侵害されたPod内からの横展開（PoCのイメージ）
curl http://backend-api.internal:8080/admin/dump-db-credentials
これを防ぐ唯一の道は、「通信の最小特権原則」だ。
—
2. 実装：デフォルト拒否（Deny All）から始める
まず、クラスターの各Namespaceで、すべての通信を遮断する「Deny All」ポリシーを適用する。これが全ての基本だ。
deny-all.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: secure-app
spec:
podSelector: {} # 空にすることで全Podを選択
policyTypes:
- Ingress
- Egress
これを適用すると、アプリは沈黙する。ここから、必要な通信だけを「許可」していく作業に入る。
—
3. 実践：マイクロセグメンテーションのホワイトリスト設定
例えば、「Webフロントエンド(Frontend)」から「APIサーバー(Backend)」への通信のみを許可する設定はこうなる。
allow-frontend-to-backend.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend-to-backend
namespace: secure-app
spec:
podSelector:
matchLabels:
app: backend # 許可される側のラベル
ingress:
- from:
- podSelector:
matchLabels:
app: frontend # アクセス元のラベル
ports:
- protocol: TCP
port: 8080 # APIがリッスンしているポート
重要なポイント：Ciliumの可視化を活用する
標準のK8s NetworkPolicyだけでは、どの通信が拒否されたのかを追いかけるのは困難だ。ここで Cilium の `Hubble` を導入してほしい。`hubble observe` を使えば、どのPod間通信がポリシーによってDROPされたのかがGUIやCLIで一目瞭然になる。
「設定したけど繋がらない」というトラブルシューティングにおいて、この可視化は最強の武器になる。
—
4. アプリケーションコード側での防衛（防御的コーディング）
ネットワークポリシーは外周の壁だが、アプリ内での入力値バリデーションは「最後の砦」だ。PHPでのファイル読み込み処理を例に、セキュアな実装を提示する。
—
5. チーフからの教訓
ネットワークポリシーを完璧に設定しても、設定ミスでシステムがダウンすれば元も子もない。だからこそ、現場では以下のプロセスを徹底してほしい。
1. 開発環境でのプロファイリング: まずはポリシーを `Audit` モード（Cilium等で可能）で動かし、正常な通信フローをすべてログに書き出す。
2. Infrastructure as Code (IaC): 手動で `kubectl apply` は禁止だ。GitOps（ArgoCDやFlux）で管理し、ポリシー変更は必ずプルリクエストを通すこと。
3. CI/CDパイプラインへの組み込み: `kube-linter` や `polaris` 等のツールで、ネットワークポリシーが定義されていないPodをデプロイ時に検知・拒否する仕組みを作る。
「面倒くさい」はセキュリティの敵だ。だが、その面倒くささを自動化し、仕組み化するのがエンジニアの腕の見せ所だ。君たちの手で、堅牢なクラスターを作り上げてくれ。期待している。
コメント