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.
Table of contents
What auditors ask platform teamsA multi-plane topologyHow the topology holds upHow the platform layer meets the infrastructure layerSovereignty as declarative configurationWhat the topology does and does not give youTakeawaysQuestions 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.