Cloud native platform sovereignty is not determined solely by where a workload runs or its data is stored. According to an analysis published by CNCF on August 18, 2026, written by Chamod Perera, a CNCF Ambassador, and Suvin Kodituwakku, a Senior Software Engineer at WSO2, demonstrating sovereignty also depends on where control state resides, the paths followed by logs and metadata, the parties able to access keys and credentials, and the team’s ability to continue operating if the provider’s service disappears.
The analysis proposes viewing sovereignty as a property of the platform’s topology, rather than merely selecting a region from a settings list. It uses OpenChoreo, an open-source internal developer platform and a CNCF Sandbox-stage project, as an inspectable example of this approach, while emphasizing that the architectural principles are not limited to it.
Four Questions That Go Beyond Server Location
The article argues that, amid frameworks such as the EU Data Act, NIS-2, DORA, and the UK Data Use and Access Act, platform teams must answer practical questions that go beyond identifying a geographic region. The first is: What legal jurisdiction governs each component that can touch tenant data, including the control plane and logs? The second is: Can the team run, rebuild, and move workloads if the provider-hosted service stops?
The other two questions concern whether parties outside the borders can access keys, cluster state, or administrative credentials, and whether changing the provider, hardware, or country requires rewriting the workload. The analysis concludes that these questions focus primarily on where control and state reside, and who has the ability to access them.
How Does the Multi-Level Architecture Work?
OpenChoreo divides the platform into independent clusters, each with its own lifecycle, security boundaries, and scaling behavior:
- Control level: Maintains desired state through declarative APIs and runs reconciliation units, but does not run tenant workloads.
- Data levels: Compatible Kubernetes clusters that actually run workloads, each with an independent API server and state.
- Observability levels: Collect and serve logs, metrics, and tracing data.
- Workflow levels: Execute CI and GitOps operations.
- Experience level: Provides the developer portal, CLI, APIs, and MCP.
The most important element is the communication model. The data, observability, and workflow levels open outbound, mutually authenticated connections over mTLS to the control-level gateway, while the control level does not initiate connections to them. As a result, the API servers of clusters hosting regulated workloads are not exposed to the internet. The control level also retains desired state, not the tenant’s complete operational state; therefore, the data level can continue serving requests even when connectivity to the control level is lost.
What Changes in Practice for Platform Teams?
Each data level can be associated with a specific legal jurisdiction, making the “one jurisdiction, one data level” model reviewable and auditable. Each data level also sends its operational data to a regional observability level instead of passing logs and traces through the control level. This keeps tenant workloads and their telemetry within the specified regional boundaries.
Continuity away from the provider depends on each data level being a complete, compatible Kubernetes cluster, rather than a closed managed endpoint. The analysis points to the use of open-source components from the CNCF and cloud native ecosystem, such as Argo Workflows, Cloud Native Buildpacks, OpenSearch, Prometheus, OpenTelemetry, Flux, cert-manager, and Cilium. The modular architecture allows a component to be replaced or an existing observability system to be connected through the same query interface.
Secrets and key protection are delegated to a store compatible with the External Secrets Operator or to a vault selected by the operating organization, instead of imposing default key ownership. Fine-grained permissions can also be applied at the level of namespaces, projects, and components, with groups connected to any OAuth2/OIDC identity provider, whether the caller is a developer, a CLI tool, or an artificial intelligence agent.
Integrating Virtual Clusters with Platform Levels
This model does not eliminate the tenant-cluster pattern; it complements it. A virtual cluster gives each tenant a virtual control plane, API server, and private store within a shared host cluster, isolating control state between tenants at a lower cost than a dedicated cluster for each one. However, it does not by itself determine the jurisdiction in which the tenant should be hosted, where logs should be sent, or who is authorized to promote the workload between two environments or regions.
This is where the platform layer adds distribution and operational controls. A DataPlane resource can carry a legal-jurisdiction label and link an observabilityPlaneRef resource to a regional observability level, while promotion paths define the environments between which the workload may move. The developer portal also provides ready-made paths that reduce the need to grant users direct access to sensitive clusters.
However, this combination has a clear limitation: tenants on the same host share the node and operating-system kernel. If the threat model requires hardware isolation for each tenant, a virtual cluster will not be sufficient, and an independent physical data level will be required.
Sovereignty as Declarative and Auditable Configuration
The analysis proposes representing the topology through declarative Kubernetes resources and storing them in Git: which region uses which data level, which destination receives observability data, and which promotion paths are permitted. Thus, creating a new jurisdiction becomes a reviewable pull request, and answering why a tenant’s data exists in a particular region is based on a change history rather than a screenshot from a dashboard.
Nevertheless, a multi-level architecture does not change the legal jurisdiction of the entity operating the infrastructure, nor does it eliminate its exposure to the legal systems to which it is subject. It draws boundaries but does not by itself enforce policies concerning what happens within them; supply-chain attestation, SBOM, audit logging, and workload identity through tools such as SPIFFE/SPIRE remain separate controls that need to be integrated.
Operational cost is a final constraint: every additional cluster requires monitoring, upgrades, and backups. Therefore, the architecture is justified when the boundaries drawn carry genuine legal or security weight, and it may be excessive in environments that do not require this. The conclusion is that combining tenant clusters for resource isolation, a multi-level architecture to define what may cross boundaries, and declarative configurations that can be version-controlled transforms sovereignty from a contractual promise into a property that can be operated and reviewed.