Cilium mTLS 暗号化は、アプリケーションの変更や追加のネットワーク スタックの導入を必要とせずに、Kubernetes のポッド間トラフィックに対して透過的な相互 TLS (mTLS) 暗号化と認証を提供します。
これにより、トラフィックが交換される前に、ソースワークロードと宛先ワークロードの両方が暗号化で認証されます。 このアプローチにより、Kubernetes ワークロードのゼロ トラスト ネットワーク モデルが可能になります。
すべての暗号化と認証はアプリケーション 層の下で行われます。つまり、mTLS の恩恵を受けるためにワークロードを変更、再構築、または再起動する必要はありません。
AKS の Cilium mTLS 暗号化は 、Advanced Container Networking Services (ACNS) 機能セットの一部であり、その実装は Cilium に基づいています。
Important
AKS のプレビュー機能は、セルフサービスのオプトイン単位で利用できます。 プレビューは、"現状有姿のまま" および "利用可能な限度" で提供され、サービス レベル アグリーメントおよび限定保証から除外されるものとします。 AKS プレビューは、ベストエフォート ベースでカスタマー サポートによって部分的にカバーされます。 そのため、これらの機能は運用環境での使用を目的としていません。 詳細については、次のサポート記事を参照してください。
アーキテクチャ
Cilium mTLS は、大まかに言えば、ID 発行、透過的なトラフィック傍受、ワークロード レベルの暗号化の適用を組み合わせることで、トラフィックをセキュリティで保護します。
各ワークロードには、名前空間や ServiceAccount などの Kubernetes 属性から派生した暗号化 ID が割り当てられます。 ポッド間 TCP トラフィックが開始されると、トラフィックはノード レベルで透過的に傍受されます。 トラフィックは、宛先ワークロードに転送される前に、相互 TLS を使用して認証および暗号化されます。
システムは、次の 3 つの連携コンポーネントで構成されます。
- SPIRE - ワークロード ID と証明書の発行を提供します。
- ztunnel - データ プレーンに mTLS を適用します。
- Cilium - ポート 15001 で送信トラフィックを ztunnel にリダイレクトする iptables ルールをインストールします。
これらのコンポーネントを組み合わせることで、認証と暗号化がクラスター全体で透過的かつ一貫して行われるようにします。
ID と認証モデル
Cilium mTLS では、SPIFFE ワークロード ID に基づく相互認証が使用されます。
各ワークロードには、次から派生した SPIFFE ID (SVID) が割り当てられます。
- Kubernetes 名前空間
- Kubernetes ServiceAccount
ワークロードが接続を開始する場合:
- ソース ztunnel は、ワークロードの有効な SVID を取得します。
- 宛先 ztunnel は、提示された ID を検証します。
- トラフィックのフローが許可される前に、両方の側が相互検証を完了します。
認証の決定は、ネットワークの場所ではなくワークロード ID に基づいています。 この設計により、次のことが保証されます。
- 認証されたワークロードのみが通信できます。
- ID は、再スケジュールとスケーリングの間で一貫性を維持します。
- 信頼は、IP アドレス指定やネットワーク トポロジに依存しません。
暗号化フロー
認証が成功すると、トラフィックは相互 TLS を使用して保護されます。
- ポッド ネットワーク名前空間内でインターセプトされ、ローカル ztunnel インスタンスにリダイレクトされたトラフィック。
- ソース ztunnel は、宛先 ztunnel との mTLS セッションを開始します。
- 証明書は交換され、検証されます。
- アプリケーション データは転送前に暗号化されます。
- 宛先 ztunnel はトラフィックを復号化し、ターゲット ポッドに配信します。
登録済みポッドからのすべてのパケットが暗号化されます。 プレーンテキスト ウィンドウはなく、最初のパケットもドロップされません。 接続は、mTLS トンネルが確立されるまで ztunnel によってインラインで保持され、トラフィックは HBONE (HTTP/2 CONNECT) トンネルを経由して双方向に流れます。
コア コンポーネント
SPIRE (ID と信頼)
SPIRE (SPIFFE ランタイム環境) は、ワークロード ID と証明書の管理を担当します。 SPIRE には、SPIRE サーバーと SPIRE エージェントという 2 つの主要なコンポーネントがあります。
SPIRE サーバーは、クラスター証明機関 (CA) として機能します。 有効期間が短い X.509 証明書 (SVID) は、ID を受け取ることが許可されているワークロードにのみ発行されます。 Kubernetes ネイティブ構成証明を使用し、IP アドレスなどのネットワーク プロパティではなく、名前空間や ServiceAccount などの属性に ID をバインドします。
各ノードで、 SPIRE エージェント は、ノードを SPIRE サーバーに対して構成証明し、ローカル ワークロードに代わって証明書を取得する役割を担います。 ワークロードは SPIRE エージェントとのみ通信し、SPIRE サーバーと直接通信することはありません。
SPIRE は、すべてのワークロード ID が保証されることを確実にします。
- 暗号的に検証可能。
- 自動的に発行され、回転されます。
- IP アドレスではなく、Kubernetes プリミティブにバインドされます。
- ポッドの再起動とイベントの再スケジュールの間で安定しています。
この ID 基盤により、トポロジに依存しない強力な信頼の決定が可能になります。
Ztunnel (mTLS データ プレーン)
Ztunnel は、ワークロード間で mTLS を適用する、ノード レベルの軽量レイヤー 4 プロキシです。 ノードごとに 1 つのインスタンスを含む DaemonSet として実行されるため、ポッドごとのサイドカー プロキシは不要です。
ワークロードが TCP 接続を開始すると、ztunnel はピア ノードの ztunnel インスタンスと相互に認証された TLS セッションを確立します。 SPIRE から取得した証明書を使用して、トラフィックのフローを許可する前に、接続の両側を認証します。
Ztunnel では、次の保証が適用されます。
- 接続の両側には、有効なワークロード証明書が必要です。
- 証明書は、クラスター信頼ドメインに対して検証されます。
- トラフィックは常にネットワーク上で暗号化されます。
- 登録されたワークロードに対してプレーンテキスト フォールバックは許可されません。
ノード レベルで mTLS の適用を一元化することで、ztunnel はポッドごとの運用オーバーヘッドを増やすことなく、強力なセキュリティ プロパティを提供します。
Cilium (リダイレクトルールとポッド登録)
Cilium は、mTLS をアプリケーションに対して透過的にする役割を担います。
名前空間に "io.cilium/mtls-enabled=true" というラベルが付いている場合、Cilium エージェントはその名前空間にすべてのポッドを登録します。 各ポッドのネットワーク名前空間に入り、ポート 15001 で送信トラフィックを ztunnel にリダイレクトする iptables ルールをインストールします。
Cilium は、ポッド UID などのワークロード メタデータを ztunnel に渡し、Cilium オペレーターと統合して、ワークロード ID を SPIRE に登録します。
アプリケーションの観点から見ると、通信は引き続き標準 TCP ソケットを使用します。 暗号化と認証はアプリケーションレイヤーの下に完全に適用され、コードを変更する必要はありません。
スコープと信頼の境界
名前空間の登録
Cilium mTLS はオプトインされ、名前空間レベルでスコープが設定されます。 mTLS の適用を有効にするには、名前空間に明示的にラベルを付ける必要があります。 有効にすると、その名前空間内のすべてのポッドに、必須の認証と暗号化が適用されます。
登録されていない名前空間のポッドは影響を受けません。 この設計により、段階的なロールアウトと環境間での段階的な導入が可能になります。
強制モデル
暗号化は、両方のポッドが登録されている場合にのみ適用されます。 登録済みワークロードと登録されていないワークロード間のトラフィックは、接続の問題やハード エラーを引き起こすことなくプレーンテキストで続行されます。
| 情報源 | 行き先 | 結果 |
|---|---|---|
| 登録済み | 登録済み | Encrypted (hBONE 経由の mTLS) |
| 登録済み | 登録されていない | プレーンテキストのパススルー |
| 登録されていない | 登録済み | プレーンテキスト (ztunnel によってキャプチャされますが、暗号化されません) |
| 登録されていない | 登録されていない | 通常の Cilium データパス (ztunnel の関与なし) |
考慮事項と制限事項
- この機能は、 高度なコンテナー ネットワーク サービス (ACNS) が有効な Cilium を利用する Azure CNI を使用するクラスターでのみ使用できます。
- mTLS は名前空間レベルで有効になっています。 登録された名前空間内のすべてのポッドが mTLS に参加します。 ポッド レベルのオプトインまたはオプトアウトはサポートされていません。
- Cilium mTLS は現在、TCP ベースのポッド間トラフィックを保護します。 現在、UDP を含む他のプロトコルの暗号化や認証は行われません。
- 現在のフェーズでは、L4/L7 ネットワーク ポリシーの適用は mTLS ではサポートされていません。
- カスタム CA を持ち込むことはできません。 SPIRE はクラスター証明機関として機能し、証明書の発行とローテーションを管理します。
- 同じクラスターで mTLS と WireGuard の両方を有効にすることはサポートされていません。
- Istio と Cilium mTLS 暗号化の両方の有効化はサポートされていません。
- クラスター間トラフィックの mTLS 暗号化はサポートされていません。
- 統合にはカーネルでの iptable のサポートが必要であり、iptable をサポートしていない環境 (一部の最小コンテナー ランタイムなど) では使用できません。
- ネットワーク名前空間パスのないポッド (ホスト ネットワーク ポッドなど) は ztunnel に登録できないため、登録プロセス中に除外されます。
料金
Important
アドバンスト コンテナー ネットワークサービスは有料オファリングです。 価格の詳細については、「アドバンスト コンテナー ネットワークサービス - 価格」を参照してください。
次のステップ
AKS に Cilium mTLS 暗号化 を適用する方法について説明します。
Azure Kubernetes Service (AKS) 用の Advanced Container Networking Services の詳細については、「Azure Kubernetes Service (AKS) の Advanced Container Networking Services とは?を参照してください。