Better application networking and security with CAKES
CAKES スタックについて
CAKESは、モダンなアプリケーションのネットワーキング、セキュリティ、コンプライアンスの課題に対処し、より迅速なソフトウェア開発を実現するためのオープンソースのアプリケーションネットワークスタックです。
- K - Kubernetes が中心
- C - CNI(Cilium、Calico)がコンテナネットワークを担当
- A - Istio によるサービスメッシュ
- E - EnvoyがAPIゲートウェイの役割
- S - SPIFFE/SPIREがワークロードIDを提供
CAKESは、宣言型の構成、ワークロードIDの活用、標準的な統合ポイントを基本コンセプトとしています。これにより、インフラから独立したポリシー管理が可能になり、コンプライアンス監査が容易になるとしています。
また、プラットフォームエンジニアリングチームがCAKESを活用することで、アプリケーション開発チームに最適なデベロッパーエクスペリエンスを提供でき、開発の民主化と高速化を実現できるといいます。
つまり、CAKESはKubernetesをベースにしたモダンなネットワーキング/セキュリティスタックであり、宣言型の構成とワークロードIDによる包括的なポリシー管理で、高速なソフトウェア開発を実現することを目的としています。
Table of contents
CAKESの主な利点
- 宣言型の構成でインテントとの差分が分かりやすい
従来の複雑なファイアウォールルールに比べ、宣言型の構成によりインテントした状態と実際の状態の差分が一目でわかる。コンプライアンス監査が容易になる。
- ワークロードIDによりポリシービットロットを回避
IPアドレスではなく、ワークロードIDに基づいてポリシーを記述することで、インフラの変更によるポリシー無効化(ポリシービットロット)を防げる。
- 標準の統合ポイントでシステム間の連携が容易
オープンな標準の統合ポイントを持つため、異なるシステム間の連携が容易になる。
- プラットフォームチームによる一元管理で開発の民主化
プラットフォームエンジニアリングチームがCAKESを活用し、開発者に最適化されたエクスペリエンスを提供することで、開発の民主化と高速化が実現できる。
- オープンソース技術の活用でコスト削減
オープンソースのCAKES技術を活用することで、プロプライエタリなツールに比べてコストを抑えられる。
要するに、CAKESは宣言型の構成、ワークロードID、標準の統合ポイントにより、コンプライアンスと開発の俊敏性を両立できる新しいアプリケーションネットワークスタックと位置付けられています。
CAKESを構成する具体的なオープンソース技術が挙げられています。
C - CNI (Container Network Interface)
- Cilium
- Calico
A - サービスメッシュ
- Istio
K - コンテナオーケストレーション
- Kubernetes
E - APIゲートウェイ
- Envoy
S - ワークロードIDとセキュリティ
- SPIFFE/SPIRE
このように、CAKESはコンテナネットワーキング、サービスメッシュ、コンテナオーケストレーション、APIゲートウェイ、ワークロードIDの各層で主要なオープンソーステクノロジーを採用しています。
特に注目されているのが、Cilium、Istio、Envoy、SPIFFE/SPIREといった、クラウドネイティブなネットワークとセキュリティを担うオープンソースプロジェクトです。これらを組み合わせることで、モノリシックなネットワーク/セキュリティ製品に比べ、よりクラウドフレンドリーでコスト効率の良いスタックが実現できるとされています。
CAKES スタックにおいて、マイクロセグメンテーションの機能は主に以下の2つの技術が担っています。
CNI (Container Network Interface) レイヤー
- Cilium
- Calico
Cilium や Calico はコンテナネットワークインターフェイスを提供する際に、マイクロセグメンテーション機能も備えています。ポリシーに基づいて個々のワークロードやコンテナ間の通信を細かく制御できます。
サービスメッシュレイヤー
- Istio
Istio はサービスメッシュ機能を提供しますが、その中でマイクロセグメンテーション的な機能も果たしています。Istioを使えば、サービスごとにL7トラフィックのルーティング、マイクロ認可などのポリシーを適用できます。
つまり、CNIレイヤーではコンテナ/ワークロード間の通信制御、サービスメッシュレイヤーではL7のサービストラフィック制御という形で、CAKESにはマイクロセグメンテーションの機能が盛り込まれているということです。
はい、CAKESスタックではマイクロセグメンテーションのポリシーを宣言的に設定できます。
CNIレイヤー(Cilium/Calico)のポリシー設定
Ciliumの場合はCilium NetworkPolicy、CalicoではCalico NetworkPolicyといったカスタムリソースを使って、ネットワークポリシーを宣言的に定義できます。例えば以下のようになります。
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: app-micro-segmentation
spec:
endpointSelector:
matchLabels:
app: myapp
ingress:
- fromEndpoints:
- matchLabels:
tier: frontend
toPorts:
- ports:
- port: "9090"
protocol: TCP
サービスメッシュレイヤー(Istio)のポリシー設定
IstioではVirtualService、DestinationRule、AuthorizationPolicyなどのカスタムリソースを使ってL7ルーティングやセキュリティポリシーを宣言できます。
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: Frontend-Ingress-Policy
spec:
selector:
matchLabels:
app: frontend
rules:
- from:
- source:
principals: ["cluster.local/ns/ingress/sa/ingress-sa"]
to:
- operation:
paths: ["/productinfo/*"]
このようにCAKESスタックでは、CNIレイヤーとサービスメッシュレイヤーの両面で、宣言的にマイクロセグメンテーションポリシーを定義できます。これらは全てGitOpsワークフローに組み込め、自動化が容易です。
マイクロセグメンテーションのポリシーを具体的に設定する方法について説明します。
マイクロセグメンテーションは、ネットワーク内の通信を細かく制御するためのセキュリティ手法です。ポリシーの設定により、ワークロード間のトラフィックを制限し、セキュリティを強化することができます。
マイクロセグメンテーションのポリシーを具体的に設定する方法を示します。
- ネットワークの可視化: マイクロセグメンテーションを実施する前に、ネットワーク全体の可視化を行います。ネットワーク内のワークロードやアプリケーションの特定、通信パターンの把握などを行いましょう。
- ラベルの設定: ポリシーを設定するために、ネットワーク上のデバイスやアプリケーションにラベルを付けます。ラベルは、何を守るかを明確にするためのものです。
- ポリシーの定義: ポリシーは、ネットワーク上のデバイスやアプリケーションが通信可能なセグメントを定義するものです。以下のような要素を考慮してポリシーを設定します。
- ラベル単位: 特定のラベルを持つデバイスやアプリケーション同士の通信を制限します。
- ドメインやサブネット単位: 特定のドメインやサブネット内のデバイスやアプリケーション同士の通信を制限します。
- プロセス単位: 特定のプロセスが実行されているデバイスやアプリケーション同士の通信を制限します。
- ポリシーの管理: ポリシーの設定後は、定期的なポリシーの管理が重要です。新たなワークロードやアプリケーションの追加、変更があった場合には、ポリシーを適切に更新し、セキュリティを維持します。
- ポリシーの監視と評価: ポリシーの効果を確認するために、ポリシーの監視と評価を行います。異常な通信やセキュリティ侵害の試みがあった場合には、ポリシーを見直し、必要に応じて修正します。
以上が、マイクロセグメンテーションのポリシーを具体的に設定する方法です。ポリシーの設定には、ネットワークの可視化やラベルの設定、ポリシーの定義、ポリシーの管理、ポリシーの監視と評価が含まれます。