はじめに
Kubernetesは現代のクラウドネイティブ環境におけるコンテナーオーケストレーションの基盤として広く採用されています。しかし、その內部サービス間（east-west）の通信におけるセキュリティリスクは、DDoS攻撃や持続的な脅威行動者（persistent threat actors）といった外部脅威だけでなく、離職した社員や內部の混亂を引き起こす攻撃（confused deputy attack）など、內部からの脅威にも対応する必要があります。このため、ゼロトラスト（Zero Trust）の原則に基づき、標準化されたアイデンティティと認証ポリシーの導入が不可欠です。本記事では、Kubernetesにおける標準化されたアイデンティティの重要性、現狀の課題、およびCNCF（Cloud Native Computing Foundation）における標準化の必要性について詳しく説明します。
標準化されたアイデンティティと認証ポリシー
Kubernetesにおける認証ポリシーの課題
Kubernetesでは、ネットワークポリシー（NetworkPolicy v1）が內部通信の制御に用いられてきました。しかし、このアプローチには以下のような制限があります：
- 暗黙の拒否（Implicit Deny）：明示的に許可されていないトラフィックは自動的に拒否されるが、この仕組みは誤った制御を引き起こす可能性がある。
- IPベースのアイデンティティ識別：IPアドレスやラベルセレクター（label selector）を基にトラフィックを制御するが、サービスアカウント（ServiceAccount）などの直接的なアイデンティティと結びつけることができない。
- 拡張性と一貫性の問題：ラベルセレクターのクエリ効率が低く、最終一貫性（Eventual Consistency）が原因で過剰な許可（Permissiveness）が発生する。
- クラスタ管理能力の欠如：クラスタレベルのポリシーを定義できず、ネームスペース（Namespace）レベルに限定される。
これらの課題に対応するため、アイデンティティベースの認証モデルが求められています。
イデントティティベースの認証モデルの課題
アイデンティティをネットワークポリシーに統合するには、以下の問題が殘ります：
- アイデンティティのソース：PodからサービスアカウントやJWT、証明書などの一意な識別子をどのように取得するか。
- アイデンティティのエンコード：ネットワーク通信でアイデンティティをどのように表現するか（例：JWT、X.509証明書）。
- トランスポートレイヤー：アイデンティティ情報がどのネットワークレイヤー（OSIモデル）で利用可能か。
- プロトコル間の互換性：TCP、HTTP、gRPCなどの異なるプロトコルでアイデンティティ情報を識別・適用できるか。
これらの課題を解決するため、現行の解決策（Psyllium、Pod Identityなど）の比較と統合が求められます。
現行の解決策とその比較
Psyllium
- ラベルセレクターでアイデンティティを定義し、進出トラフィックを制御可能。
- アイデンティティがPod間で共有され、パフォーマンス向上が期待される。
- ただし、サービスアカウントとの直接的なバインディングができない。
Pod Identity
- サービスアカウントとPodを一対一でバインディングし、進みだけのトラフィック制御をサポート。
PodIdentityリソースで許可/拒否ルールを定義可能。
異なる実裝の課題
- 異なる実裝間での標準化が不足し、ツール間の統合が困難。
- アイデンティティの伝達・解析メカニズムが統一されていないため、ポリシーの実行の一貫性が保たれない。
アイデンティティの範囲と目標
Kubernetesの基本的なワークロード
- Podが基本単位だが、VM、ホスト、サービスアカウントなどの他の実體も考慮が必要。
イデントティティの種類
- サービスアカウント（ServiceAccount）：Kubernetesのネイティブアイデンティティで、Podとバインディング。
- JWT/OIDC：人間ユーザーまたは機械間認証に使用。
- 証明書（X.509）：AWS IAM、GCP ServiceAccountなどのクラウドサービスで使用。
ポリシーの目標
- アイデンティティをソース（Source）またはターゲット（Target）として利用可能。
- 多様なアイデンティティタイプをサポートし、Pod、ネームスペース、クラスタレベルでのポリシー適用を可能に。
実裝の考慮とトレードオフ
ポリシーAPIの設計
- アイデンティティの抽出、エンコード、トランスポートレイヤー、適用場面を明確に定義。
- クラスタスコープとネームスペーススコープのポリシーをサポート。
拡張性
- ラベルセレクターのクエリ効率問題を迴避し、より効率的なアイデンティティインデックスメカニズムを採用。
- 最終一貫性による過剰な許可を防ぐため、強い一貫性（Strong Consistency）メカニズムを導入。
ツールエコシステム
- 現行ツール（Psyllium、Pod Identityなど）と新規標準の統合を図り、重複実裝を迴避。
- CNCF內での標準化プロトコルの推進により、クロウドネイティブ環境での互換性を確保。
結論
Kubernetesにおける標準化されたアイデンティティの導入は、內部通信のセキュリティ強化と、持続的な脅威行動者やDDoS攻撃への対応を可能にします。現行のNetworkPolicy v1の限界を克服し、アイデンティティベースの認証モデルを実裝するには、以下の課題を解決する必要があります：
- クラスタスコープとネームスペーススコープでのポリシー統合
- プロトコル間の互換性と一貫性
- CNCFによる標準化プロセスの推進
今後の方向性として、Cubletなどの技術の活用や、ネットワーククラス（Network Class）概念の検討が重要です。標準化されたアイデンティティの実裝により、Kubernetes環境のセキュリティと運用効率が向上し、持続的な脅威への対応が可能になります。