[Cilium] Kubernetesセキュリティの核心、Service Accountベースのネットワークポリシー完全ガイド 🛡️

8月 12, 2026

—

こんにちは！今日は、Kubernetesネットワークセキュリティの「最終兵器」とも呼ばれるCiliumを活用して、より安全で直感的なセキュリティポリシーを確立する方法について深く掘り下げていきます。

特に、単にLabel（ラベル）を使用するだけでなく、Service Account（サービスアカウント）を活用してポリシーを構築する方法とその理由について詳しく解説します。🚀

🧐 なぜLabelだけでは不十分なのでしょうか？

基本的なKubernetes NetworkPolicyは、Podに付与されたLabel（app: frontendなど）を基準にトラフィックを許可またはブロックします。しかし、ここには致命的なセキュリティ上の欠陥が存在する可能性があります。

偽装の可能性 (Spoofing): 開発者や攻撃者が悪意を持ってPodを起動し、app: frontendというラベルを任意に付与した場合、ファイアウォールはそれを区別できずに通過させてしまいます。😱
管理の複雑さ: Podのバージョンが変更されたり、デプロイ戦略が変わるたびに、ラベル管理が混乱しやすくなります。

💡 解決策: Service Account (SA) ベースのポリシー

CiliumはID（Identity）ベースのセキュリティを提供します。Podが作成される際に割り当てられるService Accountは、Kubernetes RBAC（Role-Based Access Control）によって厳密に管理されるため、ラベルよりもはるかに信頼性の高い識別子です。

つまり、「このラベルを持つPod」ではなく、「この身分証明書（SA）を持つPod」のみを通過させるという意味です。

🛠️ 動作原理: io.kubernetes.serviceaccount.name

Ciliumは、Podが作成される際にそのPodのService Account情報を読み取り、内部的に特殊なラベルに変換して管理します。

キー(Key): io.kubernetes.serviceaccount.name
値(Value): 実際のService Account名（例: frontend-sa）

この特殊なラベルをCiliumNetworkPolicy (CNP)で使用することで、非常に精密なルールを作成できます。

📝 実践設定ガイド (YAML例)

状況を仮定してみましょう。

目標: frontend-saというService Accountを使用するPodのみがbackend Podにアクセスできるようにする必要があります。

1. CiliumNetworkPolicyの作成

YAML

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "secure-backend-access"
  namespace: "default"
spec:
  # 1️⃣ 宛先設定: 誰を保護するか？ (Backend)
  endpointSelector:
    matchLabels:
      app: backend

  # 2️⃣ インバウンドルール (Ingress): 誰が入ってこれるか？
  ingress:
  - fromEndpoints:
    - matchLabels:
        # 3️⃣ 重要ポイント！Service Account名を指定
        io.kubernetes.serviceaccount.name: "frontend-sa"

        # (オプション) 同じネームスペースであることを明示したい場合
        io.kubernetes.pod.namespace: "default"

🔍 詳細分析

endpointSelector: ポリシーが適用される対象です。ここでは、app: backendラベルを持つPodが保護対象となります。
fromEndpoints: アクセスを許可するソース（出発地）を定義します。
io.kubernetes.serviceaccount.name: ここが魔法が起こる場所です！🎩 一般的なappラベルの代わりに、Kubernetesが保証するSA名を条件として設定しました。これで、たとえapp: frontendラベルを偽装して付与しても、SAがfrontend-saでなければアクセスはブロックされます。

🌟 Service Accountポリシーの利点まとめ

区分	一般的なNetworkPolicy (ラベル)	Cilium CNP (Service Account)
識別基準	ユーザーが任意に付与したラベル	K8sが認証したService Account
セキュリティ強度	低い（ラベル偽装が容易）	高い（RBACで制御される）
可視性	IP/ラベル中心	アプリケーション/ID中心
適用例	単純な隔離	ゼロトラスト(Zero Trust)の実装

—

🍯 ヒント: ネームスペースが異なる場合は？

もしfrontendチームのネームスペース(team-a)にあるSAがbackendネームスペース(team-b)にアクセスする必要がある場合、どうすればよいでしょうか？Ciliumはネームスペースラベルも組み合わせて使用できます。

YAML

  - fromEndpoints:
    - matchLabels:
        io.kubernetes.serviceaccount.name: "frontend-sa"
        io.kubernetes.pod.namespace: "team-a"  # 👈 ネームスペースまで指定！

このようにすることで、team-aネームスペースにあるfrontend-saサービスアカウントのみが正確に許可されます。

🏁 終わりに

Ciliumを使用するなら、もはや不安定なラベルだけに頼らないでください。Service Accountを活用することで、インフラレベルのセキュリティポリシーをアプリケーションの認証体系（RBAC）と組み合わせ、はるかに強力なDefense-in-Depth（多層防御）戦略を構築できます。

今すぐあなたのクラスターポリシーを見直してみてください！😉