CLOUD SECURITY LAB

🚨 私のクラスターは私が守る！Ciliumネットワークポリシー、これだけ知れば完璧！

—

by

cslab
in

皆さん、こんにちは！Kubernetes環境で複雑に絡み合ったサービス間の通信を見て、頭を悩ませた経験、一度はありますよね？🧐 「このPodはあのPodと通信しないと…」「あれ？このPodは絶対に外部に出てはいけないのに！」といった悩みです。

今日は、この複雑なネットワークトラフィックを明確に整理してくれる解決策、Ciliumネットワークポリシーの核心原理について学んでいきたいと思います。まるで交通整理の警察官のように、どのトラフィックを通し(Go🚦)、どのトラフィックを止めるか(Stop🛑)を決定する、非常にシンプルでありながら強力なルールです。

この記事を最後まで読めば、あなたもCiliumネットワークポリシーの専門家になれます！

🤔 Ciliumポリシー、それで核心は何？

結論から申し上げます。Ciliumネットワークポリシーを貫く最も重要な3つの核心要素は、まさに「誰が(Source)」「誰に(Destination)」「何をするか(Action)」です。

この3つだけ覚えておけば、Ciliumポリシーの半分はすでに理解したも同然です！

  1. Source (誰が送るのか？ 📤)
  • トラフィックを開始する主体を意味します。「AがBにデータを送る」という例でいうと「A」に該当します。
  • Ciliumでは、特定のラベル(label)を持つPodグループ(app=frontendなど)、特定のIP帯域(CIDR)、または他のエンティティとしてソースを明確に指定できます。
  1. Destination (誰に送るのか？ 📥)
  • トラフィックを受信する対象を意味します。上記の例でいうと「B」に該当しますね。
  • 一般的にポリシーが適用されるエンドポイント(Pod)自体を意味し、さらに特定のポート(port)番号まで指定して「80番ポートに入ってくるトラフィックだけ！」のように細かく制御できます。
  1. Action (どうするのか？ ✅)
  • ソースからデスティネーションへ向かうトラフィックがルールと一致したとき、どのような措置を取るかを決定します。
  • Ciliumの最も重要な哲学は「Default Deny（デフォルトで全て拒否）」です。つまり、何のポリシーもなければ、すべてのPod間の通信は遮断されます。したがって、私たちが作成するポリシーは、特定のトラフィックを「許可(Allow)」する「ホワイトリスト」方式になります。この「許可」がまさにActionに該当します。

🗺️ 全体像で理解する：Default Denyと許可ポリシー

個々の要素を知ることも重要ですが、全体的な流れを理解するとCiliumの強力さを真に感じることができます。

状況を仮定してみましょう。あなたのクラスターにはfrontend Podとbackend Podがあります。frontendはユーザーのリクエストを受け取り、backendにAPIリクエストを送る必要があります。

  1. ポリシー適用前 (Default Deny) 🚫
  • Ciliumが適用された環境では、デフォルトでfrontendとbackendは互いに通信できません。すべての道が塞がれている状態だと考えてください。frontendがbackendを呼び出しても応答は来ません。
  1. ポリシー適用後 (Allow Rule) ✅
  • 私たちは、frontendがbackendの8080ポートと通信することを「許可」するポリシーを作成する必要があります。
  • Source: app=frontendラベルを持つPod
  • Destination: app=backendラベルを持つPod、ポートは8080
  • Action: この通信を許可(Allow)する。

このポリシーを適用した瞬間、塞がれていた2つのPod間に安全な通信チャネルが開かれます。✨

💻 コードで直接確認する：FrontendがBackendを呼び出すことを許可する

百聞は一見に如かず！実際のCiliumNetworkPolicy YAMLファイルを通じて、上記のシナリオをどのように実装するかを見ていきましょう。このポリシーはbackend Podに適用され、frontendからの受信トラフィックを許可するルールです。

# CiliumNetworkPolicyの定義（APIバージョンと種類）
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  # ポリシーが適用されるネームスペース
  namespace: my-app
  # ポリシーの名前
  name: backend-allow-from-frontend
spec:
  # --- 宛先 (Destination) ---
  # このポリシーがどのPodに適用されるかを選択します。
  # 'app=backend'ラベルを持つすべてのPodが対象です。
  endpointSelector:
    matchLabels:
      app: backend

  # --- アクション (許可) + 送信元/宛先ポート ---
  # 'ingress'は受信トラフィックに対するルールを意味します。
  ingress:
  - fromEndpoints:
      # --- 送信元 (Source) ---
      # 'app=frontend'ラベルを持つPodからのトラフィックを許可します。
      - matchLabels:
          app: frontend
    toPorts:
      # --- 宛先ポート (Destination Port) ---
      # 8080/TCPポートへの受信トラフィックにのみこのルールを適用します。
      - ports:
        - port: "8080"
          protocol: TCP

YAMLファイル解釈：

  • endpointSelector: このポリシーのDestination(対象)が誰であるかを定義します (app=backend Pod)。
  • ingress: 受信トラフィックに対するルールであることを明示します。
  • fromEndpoints: トラフィックのSource(出発地)が誰であるかを定義します (app=frontend Pod)。
  • toPorts: Destinationの特定のポートを明示して、ルールをより細かくします。
  • このYAMLファイル自体をクラスターに適用する行為が、まさにAction(許可)を意味します。

🧐 ちょっと待って、これはなぜ正解ではないの？

似ているように見えても、核心から外れた概念もあります。これらが基本的な構造ではない理由を理解すると、概念がより明確になります。

  • ❌ Pod, Service, Namespace
  • 理由: これらはKubernetesの「オブジェクト」または「リソース」です。Ciliumポリシーはこれらのオブジェクトを活用してSourceやDestinationを「指定」しますが、ポリシー規則自体の根本的な構造（誰が、誰に、どのように）ではありません。つまり、材料であって、レシピの基本ステップではないのです。
  • ❌ Ingress, Egress, Protocol
  • 理由: Ingress（受信）とEgress（送信）はトラフィックの「方向」を示します。Protocol（TCP/UDP）は通信「規約」です。これらはポリシーを構成する非常に重要な「属性」ですが、「Source → Destination」という流れを定義するより大きな枠組みの構成要素ではありません。方向と属性は、「誰が誰に」という関係が定まった後に具体化される詳細事項です。

終わりに

Ciliumネットワークポリシーの核心が見えてきましたか？複雑に見えるYAMLファイルも、結局は「どのソース(Source)が、どの目的地(Destination)に、通信することを許可(Action)するのか？」という簡単な質問に答える過程に過ぎません。

この3つの核心原則をしっかり覚えておけば、あなたのKubernetesクラスターをどんな脅威からも安全に守る、素晴らしいセキュリティアーキテクトになれるでしょう。🚀

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です