When people talk about cloud sovereignty, the conversation often starts with regions: where a workload runs and where its data is stored. But choosing a region is only part of the story. The architecture of the platform matters just as much, particularly how it separates control, runtime, build, and observability responsibilities across clusters.
A recent CNCF community post, “From data residency to digital sovereignty: architectural patterns for cloud native platforms,” made the case well. Under regimes like the EU Data Act, NIS-2, DORA, and the UK Data Use and Access Act, platform teams now have to show more than where workloads run. They have to show how the platform is operated, secured, and governed, all the way down to the control plane.
That article laid out the requirements and introduced the tenant-cluster pattern as one way to draw isolation boundaries. In this article, we look at the same requirements from a different but complementary angle: what happens when you treat sovereignty as a property of a platform’s plane topology. We will use OpenChoreo, an open source internal developer platform and a CNCF Sandbox project, as an inspectable example. The architectural ideas apply broadly, though.
What auditors ask platform teams
The earlier post narrows down the regulatory and procurement noise into four practical properties. Rather than repeat them, we will restate them as the questions an auditor or a procurement team actually asks a platform team:
- For every component that can touch tenant data, including the control plane and the logs and metadata around it, can you name the legal jurisdiction it runs under?
- If your vendor’s hosted service disappeared tomorrow, could your team continue operating the workload, rebuild it, and move it elsewhere?
- Can anyone outside the boundary reach your keys, your cluster state, or an admin credential?
- If the provider, hardware, or country changes, does the workload move, or does it need to be rewritten?
Look at what these questions have in common. Almost none of them are about location. They are about where control and state live, and who can reach them.
A single shared Kubernetes cluster makes those questions difficult to answer cleanly. One API server, one etcd, one set of controllers and admission webhooks serve every tenant. That makes it hard to point to a clear architectural boundary during an audit.. The tenant-cluster pattern fixes this by giving each boundary its own control plane. A multi-plane platform fixes the same problem one layer up. The two patterns also work well together, as we will see later.
A multi-plane topology
OpenChoreo splits the platform into planes. Each plane is its own cluster, with its own lifecycle, its own scaling behavior, and its own security boundary:
- A control plane holds desired state through declarative APIs and runs the reconciliation controllers. It orchestrates. It does not run tenant workloads.
- One or more data planes are conformant Kubernetes clusters that actually run workloads. Each data plane has its own API server and its own state.
- One or more observability planes collect and serve logs, metrics, and traces.
- One or more workflow planes execute CI and GitOps workflows.
- An experience plane provides the developer portal, CLI, and API/MCP surfaces.
Figure 1: The multi-plane topology. Arrow direction shows who initiates the connection.
The connection model is the detail that matters most for sovereignty, and it is why the arrows in Figure 1 point the way they do. The data, observability, and workflow planes each open an outbound, mutually authenticated (mTLS) connection to the control plane’s gateway. The control plane never dials into them.
Two things follow from this. First, because the connection is outbound only, the API servers of the clusters holding regulated workloads are never exposed to the internet. Second, the control plane holds the desired state, not the tenant runtime state. It translates higher-level resources into Kubernetes resources and hands reconciliation to each data plane’s own API server. So a data plane keeps serving traffic even if it loses its link to the control plane.
That separation allows a single orchestrating control plane to work with strong regional boundaries without becoming the place where all runtime states have to live.
How the topology holds up
Question 1: Can you name the jurisdiction? With a “one jurisdiction, one data plane” model, the answer can be represented directly in the architecture and defended during an audit. Figure 2 shows what this looks like with two jurisdictions. The observability design keeps the answer clean. Each data plane reports to a regional observability plane, and the portal queries that plane directly instead of routing telemetry back through the control plane. OpenChoreo’s documentation flags exactly this pattern for multi-regional deployments under regional data-privacy rules. A tenant’s runtime state lives in its regional data plane, and its logs never leave the region either.
Figure 2: regional boundaries in practice. Workloads and telemetry stay inside the dashed lines; only the outbound mTLS link crosses them.
Question 2: can you operate without the vendor? Each data plane is a full, conformant Kubernetes cluster, not an opaque managed endpoint, and it runs fine while disconnected from the control plane. The stack underneath is open source and largely built around CNCF and cloud -native projects, including Argo Workflows, Cloud Native Buildpacks, OpenSearch, Prometheus, OpenTelemetry, Flux, cert-manager, and Cilium. The design is modular, so a team can swap a component or put an existing observability stack behind the same query interface. No single hosted service sits on the critical path.
Question 3: can outsiders reach keys, state, or credentials? The outbound-only mTLS model keeps the sensitive clusters unreachable from the internet in the first place. Secrets and keys live in whichever External Secrets Operator-compatible store or vault the team chooses, which makes key ownership a decision rather than a default. Authorization is fine grained, down to individual namespaces, projects, and components, with groups mapped from any OAuth2/OIDC identity provider. The same authorization model applies whether the caller is a developer, the CLI, or an AI agent.
Question 4: does a change of provider mean a rewrite? Workloads are represented as standard Kubernetes resources and run on conformant Kubernetes clusters, whether those clusters are in a public cloud, on premises, or on bare metal. Promotion is a first class concept. A pipeline can move a component from development on one data plane to production on another, in a different geography or provider, applying environment-specific configuration on the way. Swapping the infrastructure under a jurisdiction becomes a topology change, not a migration project.
How the platform layer meets the infrastructure layer
The earlier post built its isolation story on the tenant-cluster pattern giving each tenant a virtual cluster of its own inside a shared host cluster.It is useful to look closely at how a platform layer can sit on top of that pattern, because the two solve different parts of the sovereignty problem.
Let’s start with what a virtual cluster gives you at the infrastructure layer. Each tenant gets a virtual control plane: its own API server and its own datastore, running as pods inside a shared host cluster. Tenant A cannot see tenant B’s resources, cannot be taken down by tenant B’s misbehaving CRDs or webhooks, and cannot touch tenant B’s cluster state. That is real control plane isolation, and it costs a fraction of a dedicated cluster because one node pool serves everyone.
Now look at what the tenant-cluster pattern, by design, does not decide. It does not decide which jurisdiction a tenant lands in. It does not decide where that tenant’s logs and traces are shipped. It does not define who may promote a workload from staging in one region to production in another. It does not give developers a paved road that keeps them from hand crafting kubeconfigs against raw clusters. These are not gaps in the pattern. They are platform layer concerns, and they are exactly the concerns the four sovereignty questions keep circling back to: where state lives, where telemetry flows, who can act across a boundary, and whether any of it is provable.
This is where the layering pays off. To the OpenChoreo control plane, a virtual cluster is just another conformant Kubernetes API. Register it as a data plane, and every platform layer control in this article now applies to it:
- The
DataPlaneresource carries a jurisdiction label, so tenant placement becomes declarative and reviewable, not tribal knowledge. - The
observabilityPlaneRefpins telemetry to the regional observability plane, so a tenant’s logs inherit the same residency guarantee as its workloads. - Promotion pipelines defined at the platform layer decide which environments a component may move between, so a workload cannot drift into the wrong jurisdiction through an ad-hoc deployment.
- The same fine-grained authorization applies to every tenant, mapped from the same identity provider, whether the caller is a developer, the CLI, or an AI agent.
- Developers get golden paths and a portal instead of raw cluster access, which shrinks the number of humans who ever hold credentials to the sensitive clusters.
Figure 3 shows the composed topology: one physical host cluster per jurisdiction, virtual clusters inside it as per-tenant data planes, one control plane orchestrating all of them over the same outbound mTLS link. In principle nothing about the registration changes because the data plane happens to be virtual; if you try this and hit an edge, that is a contribution waiting to happen.
Figure 3: the two layers composed. Virtual clusters draw the tenant boundaries inside the jurisdiction; the platform layer decides what may cross any boundary, and records why.
Read the figure as a division of labor. The infrastructure layer answers “who is isolated from whom.” The platform layer answers “what is allowed to go where, and can we prove it.” Neither layer can answer the other’s question. Virtual clusters alone leave placement, telemetry routing, and promotion as manual policy enforced by hope. A platform alone, running tenants as namespaces on shared clusters, leaves every tenant one admission-webhook misconfiguration away from its neighbors. Together they cover all four sovereignty questions at a cost that scales with jurisdictions, not tenants.
One caveat belongs in the open, and Figure 3 makes it visible: tenants on the same host still share nodes and a kernel. If the threat model demands hardware isolation per tenant, a virtual cluster is not enough, and that tenant needs a physical data plane of its own. The point of a composable topology is that this, too, is just a registration decision, not a redesign.
Sovereignty as declarative configuration
The earlier post ends with an idea worth carrying forward: sovereignty should be something with a name, a template, and a commit history, rather than only a clause in a contract.
A plane topology expressed as declarative Kubernetes resources fits that idea well. Data planes, environments, and deployment pipelines are custom resources. The entire topology can live in Git: which region has which data plane, which observability sink it uses, and which promotion paths are allowed.
The manifest below is a simplified sketch with abbreviated field names. It is meant to show the shape, not an exact schema:
# Illustrative only. See the project docs for the real API surface.
kind: DataPlane
metadata:
name: eu-west
labels:
jurisdiction: eu
spec:
observabilityPlaneRef: eu-observability # telemetry stays in-region
# registry, gateway, and network settings scoped to the EU boundary
---
kind: Environment
metadata:
name: production-eu
spec:
dataPlaneRef: eu-westAdding a new jurisdiction then becomes a reviewed pull request. And when someone asks “why is this tenant’s data in this jurisdiction?”, the answer is a commit history, not a screenshot of a console.
What the topology does and does not give you
First, the multi-plane topology does not change the legal jurisdiction of the organization operating the infrastructure. If a cluster operator is subject to a particular legal regime, that exposure still exists. Where the threat model requires sovereign hardware or a sovereign operator, that decision must be made at the infrastructure layer. The topology can partition exposure and reduce its scope, but it cannot remove the legal context of the operator.
Second, the topology draws boundaries; it does not enforce what happens inside them. Policy enforcement, supply-chain attestation and SBOMs, audit logging, and workload identity through something like SPIFFE/SPIRE are separate concerns, and a sovereign deployment may need all of them. The distinction here is between the architectural pattern and the platform implementation. The pattern alone does not provide these controls, but the platform layer is a natural place to integrate them. OpenChoreo’s modular architecture is intended to support this type of integration, in the same way it already orchestrates components such as Cilium, Flux, and cert-manager. Boundary comes first, enforcement is layered on top.
Third, more planes mean more to run. Every cluster is something to monitor, upgrade, and back up. The pattern earns its cost when the boundary you are drawing carries real legal or risk weight. It is overkill when it does not. This is also where the virtual cluster composition above pays off, by keeping the number of physical clusters tied to the number of jurisdictions rather than the number of tenants.
Takeaways
The reframing in the original post holds up. Sovereignty is less about a region on a dropdown and more about how control, state, keys, and audit trails are distributed.
Seen through that lens, the interesting design question becomes how to split responsibilities: tenant clusters as the isolation primitive, a plane-separated topology as the boundary map, and, most powerfully, both together. Expressing those boundaries as declarative, version-controlled objects is what turns “sovereign” from a procurement promise into something a platform team can actually operate and audit.
OpenChoreo is an open -source CNCF Sandbox project. If you would like to explore or contribute, the code and community links are at openchoreo.dev.