--- title: "Cloud Native platform sovereignty through multi-plane architecture" url: https://daily.dev/posts/cloud-native-platform-sovereignty-through-multi-plane-architecture-ho9oxoexf source_url: https://www.cncf.io/blog/2026/08/18/cloud-native-platform-sovereignty-through-multi-plane-architecture type: article source: "CNCF" published: 2026-08-18T11:31:25.469Z updated: 2026-08-18T11:40:01.775Z tags: ["kubernetes", "platform-engineering", "multi-tenancy"] reading_time: 12 upvotes: 4 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Cloud Native platform sovereignty through multi-plane architecture **[CNCF](https://daily.dev/sources/cncf)** · 12 min read · 4 upvotes · 0 comments ## Summary Cloud sovereignty is framed as more than choosing a region: it depends on how a platform separates control, runtime, build, and observability responsibilities across clusters. Using OpenChoreo, a CNCF Sandbox internal developer platform, as an example, a multi-plane architecture (control, data, observability, workflow, experience planes) is described, where data/observability/workflow planes open outbound mTLS connections to the control plane, keeping tenant-holding API servers unexposed to the internet. This design is evaluated against four auditor questions covering jurisdiction, vendor independence, credential exposure, and portability. The piece also compares this platform-layer approach with the infrastructure-layer tenant-cluster pattern (virtual clusters), arguing the two are complementary: virtual clusters isolate tenants, while plane topology decides where state, telemetry, and promotion may cross jurisdictional boundaries. Declarative, Git-tracked topology definitions are proposed as a way to make sovereignty auditable via commit history rather than contractual promises. Limitations are noted: the topology doesn't change the legal jurisdiction of the operator, doesn't enforce policy or supply-chain security by itself, and adds operational overhead proportional to the number of planes. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How does OpenChoreo's control plane avoid exposing tenant Kubernetes API servers to the internet? Data, observability, and workflow planes each open an outbound, mutually authenticated mTLS connection to the control plane's gateway, and the control plane never dials into them. This means the API servers of clusters holding regulated workloads are never exposed to the internet, and a data plane keeps serving traffic even if it loses its link to the control plane. _Explore daily.dev coverage of platform architectures for teams designing sovereign, multi-region Kubernetes setups._ ### What is the difference between the tenant-cluster pattern and a multi-plane platform topology for cloud sovereignty? The tenant-cluster pattern gives each tenant a virtual control plane inside a shared host cluster for infrastructure-level isolation, answering who is isolated from whom, while a multi-plane platform topology (control, data, observability, workflow, experience planes) decides where state and telemetry live and what may cross jurisdictional boundaries. They are complementary: virtual clusters can be registered as data planes under a plane topology, combining both isolation and governance. _Compare architectural patterns like this on daily.dev when weighing tenant isolation strategies for regulated platforms._ ### What open source projects does OpenChoreo's stack rely on for a cloud native internal developer platform? OpenChoreo's modular stack is built around CNCF and cloud native projects including Argo Workflows, Cloud Native Buildpacks, OpenSearch, Prometheus, OpenTelemetry, Flux, cert-manager, and Cilium. The design lets a team swap individual components or put an existing observability stack behind the same query interface, avoiding dependence on any single hosted service. _Track which CNCF projects power internal developer platforms like this one on daily.dev._ ## Similar posts on daily.dev - [From data residency to digital sovereignty: Architectural patterns for cloud native platforms](https://daily.dev/posts/from-data-residency-to-digital-sovereignty-architectural-patterns-for-cloud-native-platforms-y53fpunsf) · CNCF · 0 upvotes · 0 comments - [How data sovereignty is changing cloud native infrastructure design](https://daily.dev/posts/how-data-sovereignty-is-changing-cloud-native-infrastructure-design-j0hoirdvt) · CNCF · 2 upvotes · 0 comments --- Tags: [#kubernetes](https://daily.dev/tags/kubernetes), [#platform-engineering](https://daily.dev/tags/platform-engineering), [#multi-tenancy](https://daily.dev/tags/multi-tenancy) [View this post on daily.dev](https://daily.dev/posts/cloud-native-platform-sovereignty-through-multi-plane-architecture-ho9oxoexf)