こんにちは！インフラやクラウドのセキュリティを担当していると、ネットワークの「門番」であるファイアウォールや、不正な侵入を防ぐIDS/IPSといった言葉をよく耳にするようになりますよね。
特に、最近のシステムで主流となっているKubernetes（クバネティス）の世界では、コンテナ同士がまるで一つの巨大なマンションのように密集して暮らしています。このマンションの各部屋（Pod）の間で、「誰がどの部屋に行っていいのか」をピシッと管理するのが NetworkPolicy という仕組みです。
今日は、この NetworkPolicy を本番環境に導入する際、「設定を間違えて大切な通信まで止めてしまったらどうしよう……」と不安な新人エンジニアのあなたに向けて、事前のテストと検証の手法を優しく紐解いていきたいと思います。一歩ずつ、安心して学んでいきましょう！
—
1. 家の鍵の防犯に例える NetworkPolicy
いきなりですが、あなたの自宅の玄関を思い浮かべてみてください。
通常のマンションやアパートでは、鍵を閉め忘れない限り、見ず知らずの他人が勝手にリビングに入ってくることはありませんよね。でも、Kubernetesという名の巨大マンションは、初期状態だと「全室ドアを開けっ放し、誰でも隣の部屋に自由に出入りし放題」という、セキュリティ的にはちょっとハラハラする状態でスタートします。
ここで登場するのが、各部屋のドアに厳重な電子ロックをかける NetworkPolicy です。
「データベースの部屋には、お墨付きを持ったWebサーバーの部屋からしか入れないようにする」といったルールを細かく決めることで、仮にひとつの部屋が悪い人に侵入されても、被害が他の部屋に広がらないように食い止めることができます。これがネットワークセキュリティの基本であり、泥棒（攻撃者）の横移動（ラテラルムーブメント）を防ぐ最大の防御壁になります。
—
2. なぜ「テストと検証」なしの本番適用は危険なのか？
「じゃあ、さっそくセキュリティを高めるために、厳しめのルールを全部の部屋に適用しちゃおう！」……ちょっと待ってください。それ、現場のエンジニアが一番やってはいけない「爆弾投下」になってしまうかもしれません。
もし、設定ファイル（YAMLファイル）の中にほんの少しのタイポ（入力ミス）があったり、裏でこっそり動いていた監視ツールの通信をうっかり遮断するルールを入れてしまったりするとどうなるでしょうか？
本番環境に適用した瞬間、ユーザーからのアクセスがパタッと途絶え、社内チャットが「サイトが見えません！」という悲鳴で埋め尽くされることになります。
だからこそ、「本番のドアを閉める前に、合鍵やシミュレーションツールを使って本当に正しく動くかテストする」というプロセスが絶対に欠かせないのです。
—
3. シミュレーションで安全性を確かめる実践ステップ
それでは、実際にKubernetes環境で NetworkPolicy の動作をテスト・検証する手順を見ていきましょう。今回は、テスト用のツールやコマンドを使って、通信が意図通りに「通るべきものは通る」「遮断されるべきものは遮断される」かを確認する方法を解説します。
ステップ1: 検証用のマニフェスト（設定）を用意する
まずは、テスト用の NetworkPolicy を書くところから始めましょう。今回は例として、「app: web というラベルがついたPodからしか、app: db というラベルがついたデータベースへの通信を許可しない」というルールを作ります。
以下のYAMLファイルを見てください。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: db-security-policy
namespace: default # 適用するネームスペースを指定します
spec:
podSelector:
matchLabels:
app: db # このルールは「app: db」を持つPod（データベース）を守ります
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: web # 「app: web」を持つPodからのアクセスだけを許可します
ports:
- protocol: TCP
port: 3306 # MySQLなどのデータベース用ポートを許可この設定ファイルを適用する前に、私たちは「本当にこの通りに動くか」をテストしたいわけです。
ステップ2: テスト用Podを使った「通信の疎通テスト」
Kubernetesで一番手っ取り早く、かつ確実なテスト手法は、実際にテスト用の小さなコンテナ（Pod）を一時的に立ち上げて、通信のキャッチボールを試してみることです。
例えば、app: web のラベルを持ったPodと、全く関係のない app: hater （悪意ある、あるいは無関係な）ラベルを持ったPodの2つを同じクラスター内に用意します。
そして、それぞれのPodから app: db のPodに対して通信（nc コマンドや curl コマンドなど）を飛ばしてみます。
1. 許可されている通信のテスト (app: web から app: db へ)
こちらは、ルールで許可されているため、通信が「成功（疎通あり）」するはずです。
2. ブロックされるべき通信のテスト (app: hater から app: db へ)
こちらは、ルールに該当しないため、通信がタイムアウトして「失敗（遮断）」するはずです。
ステップ3: 検証用オープンソースツールを活用する
手動でPodを立ててテストするのも良いですが、よりスマートに、かつ網羅的に検証したい場合は、コミュニティで開発されている検証支援ツール（例えば NetworkPolicy のシミュレーターや、視覚的に通信テストを行えるツールなど）を使用するのもプロの現場では一般的です。
特に、CI/CDパイプライン（GitHub Actionsなど）に組み込む形で、ポリシーの構文ミスや意図しない全遮断がないかを自動チェックする仕組みを組み込んでおくと、ヒューマンエラーを未然に防ぐ強力な盾になります。
—
4. 現場のホワイトハッカーからのアドバイス
最後に、現場でインシデントや設計ミスを見てきた私から、一つだけアドバイスを送らせてください。
セキュリティの強度は「厳しければ厳しいほど良い」というわけではありません。ガチガチに鍵をかけすぎて、自分たちのシステムすら動かせなくなっては本末転倒です。
NetworkPolicy を導入する際は、いきなり本番環境のすべてのルールを有効化するのではなく、必ずステージング環境やテスト環境でシミュレーションを行い、「どの通信が必要で、どの通信が不要なのか」のホワイトリスト（許可リスト）を正確に把握することから始めてみてください。
一歩ずつ、確認しながら進めれば、あなたの管理するクラウドインフラは必ず堅牢で美しい要塞になりますよ。それでは、次のセキュリティの旅でお会いしましょう！
コメント