【入門編】 Ciliumを用いたKubernetes NetworkPolicyのL7可視化と制御 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

皆さん、こんにちは！インフラやクラウドのセキュリティの世界へようこそ。
Kubernetes（K8s）を使ったシステム開発、日々の運用本当にお疲れ様です。

「コンテナ同士の通信制御って、なんだか難しそう…」
「従来のファイアウォール設定と何が違うの？」

そんな風に悩んでいませんか？今回は、次世代のネットワーク技術である Cilium（シリウム） と Hubble（ハブル） を使って、K8sの通信をL7（アプリケーション層）までガッチリ可視化・制御する方法を、身近な防犯のたとえ話を交えながら、一緒に一歩ずつ紐解いていきましょう！

—

1. 家の鍵で考えてみる：L3/L4とL7（アプリケーション層）の違い

まずは、セキュリティの基本を私たちの「お家」にたとえて考えてみましょう。

これまでの一般的なKubernetesのネットワーク制御（NetworkPolicy）は、いわば「玄関のドアや門の鍵」でした。

  • 「どの部屋（ポッド）からどの部屋へ移動していいか（IPアドレスやポート番号の制御）」
  • 「この隣の家からは侵入させない（L3/L4レベルの制御）」

これだけでも一定の防犯にはなりますが、少し考えてみてください。もし「配達員さん」として玄関のドアを開けたら、その人がリビングの奥まで土足で上がり込み、勝手に冷蔵庫を開けて中身を物色し始めたらどうでしょう？ 玄関の鍵（IPやポート）だけでは、家の中に入ったあとの「ふるまい」までは止められませんよね。

ここで登場するのが L7（アプリケーション層）の制御 です。これは、リビングの入り口に「執事さん」を置いて、

  • 「荷物を置くのはいいけれど、冷蔵庫を開けるのはダメ！」
  • 「この特定のパス（例: /admin）への立ち入りは一切禁止！」

といった、通信の中身（HTTPメソッドやURLのパス）まで見て判断するセキュリティになります。Ciliumを使えば、この「優秀な執事」をKubernetesの中に簡単に配置できるんです。

—

2. なぜCiliumとHubbleなのか？（eBPFという魔法の武器）

Ciliumがすごいのは、Linuxカーネルの機能である eBPF（Extended Berkeley Packet Filter） という技術をフル活用している点です。

従来のセキュリティツールは、パケット一通一通をわざわざユーザー空間と呼ばれる場所まで持ち上げて検査していたため、どうしても処理が重くなりがちでした。しかし、eBPFはLinuxカーネルの心臓部で直接パケットを安全に覗き見・制御します。いわば、家の警備員さんが玄関のぞき穴から一瞬で怪しい動きを察知して、ノータイムで追い返すようなイメージです。

そして、その警備員さんが見つけた怪しい動きや、日々の往来をリアルタイムで可視化してくれるのが Hubble（ハブル） です。Hubbleを使うと、どのアプリがどこへ、どんなHTTPリクエストを送っているのかが、まるでカーナビの交通情報のように手に取るようにわかるようになります。

—

3. 実践！CiliumでHTTPパスを制限してみよう

それでは、実際にCiliumを使って「特定のAPIパスへのアクセスだけを禁止する」設定を書いてみましょう。

以下のマニフェストファイル（YAML）は、CiliumのL7 NetworkPolicyのサンプルです。
今回は、frontend というアプリから、backend というアプリへの通信のうち、GET /public は許可しつつ、それ以外のやばそうなパスへのアクセスをバツっと遮断する例を見てみましょう。

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "l7-path-control-rule"
  namespace: "default"
spec:
  # どのアプリ（ポッド）に対する通信を制御するかを指定します
  endpointSelector:
    matchLabels:
      app: backend

  # バックエンドへの「入り口（受信）」の通信を制御します
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "80"
              protocol: TCP
            # HTTP層（L7）のルールをここで定義します
            http:
              - method: "GET"
                # パスが "/public" で始まる通信だけを許可します！
                path: "/public.*"

この設定のポイント

  • endpointSelector で、守りたいターゲット（今回は app: backend）を指定しています。
  • toPorts の中の http セクションがL7制御の心臓部です。ここで GET メソッドかつ /public.* というパスに完全一致（あるいは正規表現）するもの以外を、Ciliumが自動的にブロックしてくれます。
  • これにより、たとえ同じ backend ポッドへの同じポート（TCP 80番）であっても、隠しコマンド的なAPIや管理画面用パス（例: /admin/delete など）への不正なアクセスを綺麗に弾くことができます。

—

4. Hubbleで「誰がどこに行こうとしているか」を覗いてみる

設定を入れたら、ちゃんと意図通りに動いているか、そして変なアクセスが来ていないかを確かめたくなりますよね。ここで Hubble CLI の出番です。

ターミナルから以下のコマンドを叩いてみましょう。

# デフォルト名前空間で、HTTP通信（L7）のフローをリアルタイムで監視する
hubble observe --namespace default --protocol http

実行すると、以下のようなログが流れてきます（イメージです）。

Mar 29 10::15:20.123: default/frontend-abc-123:54321 -> default/backend-xyz-789:80. TCP Forwarded
Mar 29 10:15:20.124: default/frontend-abc-123:54321 -> default/backend-xyz-789:80. HTTP GET /public/items Forwarded
Mar 29 10:15:25.456: default/frontend-abc-123:54330 -> default/backend-xyz-789:80. HTTP GET /admin/secret Dropped (L7 Rule denied)

おっ、一番下の行に Dropped (L7 Rule denied) と出ていますね！
「誰かが /admin/secret に行こうとしたけれど、さきほど設定したL7ルールによってCiliumが水際でブロックしてくれた」ということが、一目でリアルタイムに確認できます。これがHubbleの真骨頂です。

—

まとめ：一歩ずつ、セキュアなK8sライフへ

いかがでしたでしょうか？
「Ciliumを用いたKubernetes NetworkPolicyのL7可視化と制御」と聞くと、なんだか要塞のような難解なインフラ構築をイメージしてしまいがちですが、中身を知ってみれば「家の中に優秀な執事と防犯カメラを置く」ような、とても理にかなった仕組みです。

  • L3/L4（IP・ポート）だけでは防ぎきれない、アプリケーション内部の通信制御（パスやメソッド単位）ができる
  • eBPFの力で、パフォーマンスを落とさずにカーネルレベルで安全かつ高速にブロックできる
  • Hubbleを使えば、通信の可視化が驚くほど簡単になり、インシデント時の原因究明が圧倒的にラクになる

セキュリティ対策に「一発レッドカードの魔法の薬」はありません。でも、こうしたモダンで確実なツールを一つずつ正しく導入していくことで、私たちのクラウド環境は確実に鉄壁になっていきます。

焦らず、まずは検証環境でCiliumとHubbleをデプロイし、動かしてみることから始めてみましょう。一歩ずつ、確実にスキルアップしていきましょうね！

スポンサーリンク

コメント

タイトルとURLをコピーしました