【入門編】Kubernetes Network Policiesによるマイクロセグメンテーション – アプリケーションセキュリティ & 安全な開発防御ガイド

「全部通す」は家を全開にするのと同じ？Kubernetesで始めるゼロトラストの第一歩

こんにちは。セキュリティの現場で日々、サイバー攻撃者との知恵比べをしている者です。

今日は、Kubernetes（K8s）を使っているエンジニアの皆さんに、「Pod間の通信」という、少し地味だけど死ぬほど大事なテーマについてお話しします。

皆さんが住んでいる家を想像してみてください。玄関の鍵は閉めますよね？でも、もし「家の中の部屋という部屋、すべてドアを開けっ放しにして、誰でもどこへでも行き来できる状態」だったらどうでしょう？リビングに泥棒が一人入ったら、寝室もキッチンも金庫も、すべて無防備になりますよね。

実は、Kubernetesの初期設定の多くが、まさにこの「家の中ドア開けっ放し」状態なんです。これを防ぐための「最強の鍵」が、今回紹介するNetwork Policies（ネットワークポリシー）です。

—

なぜ「全部許可」が危険なのか？

Kubernetesのデフォルト設定では、クラスター内のすべてのPodは、他のどのPodとも自由に通信できてしまいます。

もし、Webサイトを表示するための「WebサーバーのPod」が、何らかの脆弱性を突かれて乗っ取られたらどうなるか。攻撃者はそこを足がかりにして、データベース（DB）に直接アクセスしたり、機密情報が詰まった管理用Podを探し回ったりします。

これを防ぐのがマイクロセグメンテーションという考え方です。「WebサーバーからはDBのこのポートしか触らせない」「管理用Podには特定のIPからしかアクセスさせない」というふうに、最小限の通信しか許可しない「ホワイトリスト形式」で制限をかけるのです。

—

泥棒を入れないための「ホワイトリスト」設定

では、実際にどうやって制限をかけるのか、コードを見てみましょう。まずは「基本はすべて拒否」というルールを作ります。これが最強の防犯対策です。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: default
spec:
podSelector: {} # 指定なし＝全てのPodが対象
policyTypes:

Ingress # 入ってくる通信を拒否
Egress # 出ていく通信を拒否

この設定を適用した瞬間、その名前空間にあるPodは、誰とも喋れなくなります。まさに「要塞」の完成です。ここから、必要な通信だけを一つずつ許可していきます。

WebサーバーからDBへの通信だけを許可する例

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-web-to-db
spec:
podSelector:
matchLabels:
app: database # 許可されるターゲットはDBサーバー
ingress:

from:
podSelector:

matchLabels:
app: web-server # Webサーバーからの通信のみを通す
ports:

protocol: TCP

port: 5432 # PostgreSQLのポートだけ開ける

こうすることで、たとえWebサーバーが乗っ取られても、攻撃者はDBの5432ポート以外には触ることができません。被害を最小限に抑える、これがセキュリティの鉄則です。

—

現代の武器：Ciliumで「見える化」する

ここまで読んだ方の中には、「そんなに細かく設定したら、どこが繋がらないか分からなくなるのでは？」と不安になった方もいるはずです。

そこで登場するのがCiliumのような次世代のCNI（Container Network Interface）です。Ciliumには「Hubble」という強力な可視化ツールがついています。

これを使うと、「どのPodからどのPodへ通信が飛んでいるか」がグラフやマップとしてリアルタイムで表示されます。まるで家の防犯カメラで、誰がどの部屋に行こうとしているかを見張っている状態ですね。「あっ、WebサーバーがDB以外のところを叩こうとしている！」という異常な動きを直感的に発見できるのです。

—

一歩ずつ対策を学んでいきましょう！

いきなり本番環境で「全部拒否」を設定すると、システムがダウンして大騒ぎになるかもしれません。現場での進め方はこうです。

1. まずは観測する: Cilium/Hubbleを入れて、現状の通信フローを可視化する。
2. ポリシーをドラフトする: 必要な通信経路を洗い出し、段階的に許可設定を作る。
3. テスト環境で適用: 実際に通信が通るか確認し、弾かれていないかログを見る。
4. 本番へ適応: 最後に本番環境の「デフォルト拒否」を有効にする。

セキュリティは一度やって終わりではありません。皆さんの大切なアプリケーションとデータを守るために、まずは「誰がどこにアクセスできるのか？」という視点を持つことから始めてみてください。

もし設定で行き詰まったら、焦らずにネットワークのログを眺めてみてください。そこには、攻撃者やシステムの「挙動」が必ず記録されています。私たちと一緒に、安全なクラスター作りを目指していきましょう！