クラウドネイティブ・プラットフォームの主権は、ワークロードの実行場所やデータの保存場所だけで決まるものではない。CNCFが2026年8月18日に公開し、CNCFアンバサダーのChamod Pereraと、WSO2のシニアソフトウェアエンジニアであるSuvin Kodituwakkuが執筆した分析によれば、主権を証明するには、制御プレーンの状態がどこに存在するか、ログとメタデータの経路、鍵や認証情報にアクセスできる主体、そしてプロバイダーのサービスが失われた場合にもチームが運用を継続できる能力も関係する。
この分析は、主権を設定項目の一覧からリージョンを選ぶことではなく、プラットフォームのトポロジーに備わる特性として捉えることを提案している。CNCFのSandbox段階にあるプロジェクトで、オープンソースの開発者向け内部プラットフォームであるOpenChoreoを、このアプローチを検証可能な形で示す例として用いているが、アーキテクチャ上の原則はOpenChoreoに限定されない。
サーバーの所在地を超える4つの問い
この資料によれば、EU Data Act、NIS-2、DORA、UK Data Use and Access Actなどの枠組みの下で、プラットフォームチームは地理的なリージョンを特定するだけでは不十分で、実務的な問いに答える必要がある。第一に、制御プレーンやログを含め、テナントデータに触れる可能性がある各コンポーネントは、どの法域の下で運用されているのか。第二に、プロバイダーがホストするサービスが停止した場合、チームはワークロードを実行し、再構築し、移行できるのか、という問いである。
残る2つの問いは、国外の当事者が鍵、クラスターの状態、管理用認証情報にアクセスできるかどうか、そしてプロバイダー、ハードウェア、国を変更する際にワークロードを書き直す必要があるかどうかに関するものだ。この分析は、これらの問いが主に、制御と状態がどこに存在し、誰がそれらにアクセスできる能力を持つのかに焦点を当てていると結論づけている。
マルチレベル・アーキテクチャはどのように機能するか
OpenChoreoは、プラットフォームを独立したクラスターに分割し、それぞれに固有のライフサイクル、セキュリティ境界、スケーリング動作を持たせる。
- 制御レベル：宣言型APIを通じて望ましい状態を保持し、調整ループを実行するが、テナントのワークロードは実行しない。
- データレベル：ワークロードを実際に実行する互換性のあるKubernetesクラスターであり、それぞれが独立したAPIサーバーと状態を持つ。
- 監視レベル：ログ、メトリクス、トレースを収集して提供する。
- ワークフローレベル：CIとGitOpsの処理を実行する。
- エクスペリエンスレベル：開発者ポータル、CLI、API、MCPを提供する。
最も重要な要素は通信モデルである。データ、監視、ワークフローの各レベルは、mTLSによって相互認証された送信方向の接続を制御レベルのゲートウェイに開く一方、制御レベルはそれらへの接続を開始しない。これにより、規制対象のワークロードをホストするクラスターのAPIサーバーがインターネットに公開されることはない。また、制御レベルが保持するのは望ましい状態であり、テナントの完全な実行状態ではない。そのため、データレベルは制御レベルとの接続を失ってもリクエストへの対応を続けられる。
プラットフォームチームにとって実務上何が変わるのか
各データレベルを特定の法域に関連付けることで、「1つの法域、1つのデータレベル」というモデルをレビューおよび監査可能にできる。また、各データレベルは運用データを地域の監視レベルに送信し、ログやトレースを制御レベル経由で転送しない。これにより、テナントのワークロードとその測定データを指定された地域境界内に保持できる。
プロバイダーから離脱しても継続できる能力は、各データレベルが閉鎖的なマネージド・エンドポイントではなく、完全かつ互換性のあるKubernetesクラスターであることに依存する。この分析は、Argo Workflows、Cloud Native Buildpacks、OpenSearch、Prometheus、OpenTelemetry、Flux、cert-manager、Ciliumなど、CNCFおよびクラウドネイティブ・エコシステムのオープンソース・コンポーネントを使用することを示している。モジュール型アーキテクチャにより、コンポーネントを交換したり、既存の監視システムを同じクエリインターフェースに接続したりできる。
秘密情報と鍵の保護は、External Secrets Operatorと互換性のあるストア、または運用主体が選択するボールトに委ねられ、鍵のデフォルト所有権を強制しない。また、スペース、プロジェクト、コンポーネントのレベルで細かな権限を適用でき、呼び出し元が開発者、CLIツール、AIエージェントのいずれであっても、グループを任意のOAuth2/OIDCアイデンティティープロバイダーに連携できる。
仮想クラスターとプラットフォームレベルの統合
このモデルはテナントクラスターのパターンを廃止するのではなく、補完する。仮想クラスターは、共有ホストクラスター内で各テナントに仮想的な制御プレーン、APIサーバー、専用ストレージを与えるため、テナントごとに専用クラスターを用意するより低コストで、テナント間の制御状態を分離できる。ただし、テナントをどの法域でホストすべきか、ログをどこに送信するか、2つの環境またはリージョン間でワークロードをアップグレードする権限を誰が持つかを、それだけで決定するわけではない。
ここでプラットフォーム層が、配置と運用の制御を追加する。DataPlaneリソースには法域のラベルを付け、observabilityPlaneRefリソースを地域の監視レベルに関連付けられる。また、アップグレード経路によって、ワークロードが移動できる環境を指定できる。さらに開発者ポータルは、ユーザーに機密性の高いクラスターへの直接アクセスを与える必要性を減らす、すぐに利用できる経路を提供する。
ただし、この構成には明確な限界がある。同じホスト上に存在するテナントは、ノードとオペレーティングシステムのカーネルを共有する。脅威モデルがテナントごとのハードウェア分離を必要とする場合、仮想クラスターでは不十分であり、実際に独立したデータレベルが必要になる。
宣言的で監査可能な構成としての主権
この分析は、トポロジーを宣言型のKubernetesリソースとして表現し、Gitに保存することを提案している。すなわち、どのリージョンがどのデータレベルを使用するか、どの宛先が監視データを受け取るか、どのアップグレード経路が許可されるかを管理する。これにより、新しい法域の作成はレビュー可能なプルリクエストとなり、特定のリージョンにテナントデータが存在する理由を、管理画面のスクリーンショットではなく変更履歴に基づいて説明できる。
ただし、マルチレベル・アーキテクチャがインフラストラクチャを運用する主体の法的管轄を変更したり、その主体が従う法制度への対象となることをなくしたりするわけではない。また、境界を描くだけで、その内部で何が行われるかに関するポリシーを単独で強制することもない。サプライチェーンの認証、SBOM、監査ログ、SPIFFE/SPIREなどのツールを用いたワークロードのアイデンティティーは、統合を必要とする別個の制御であり続ける。
最後の制約は運用コストである。追加するクラスターごとに、監視、アップグレード、バックアップが必要になる。そのため、描かれた境界が実際に法的またはセキュリティ上の重要性を持つ場合にはアーキテクチャが正当化されるが、そうした要件がない環境では過剰になる可能性がある。結論として、リソースを分離するためのテナントクラスター、境界を越えられるものを定義するためのマルチレベル・アーキテクチャ、バージョン管理可能な宣言的構成を組み合わせることで、主権は契約上の約束から、運用および監査が可能な特性へと変わる。