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, and written by Chamod Perera, a CNCF Ambassador, and Suvin Kodituwakku, a Senior Software Engineer at WSO2, demonstrating sovereignty also depends on where control-plane state resides, the paths taken by logs and metadata, the parties able to access keys and credentials, and the team’s ability to continue operating if a provider service disappears.
The analysis proposes viewing sovereignty as a property of platform topology, rather than merely selecting a region from a configuration list. It uses OpenChoreo, an open-source internal developer platform and a CNCF Sandbox project, as an inspectable example of this approach, while emphasizing that the architectural principles are not limited to it.
Four Questions Beyond Server Location
The article states 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 operating?
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 authenticated, mutually authenticated outbound 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 runtime state; therefore, the data level can continue serving requests even when its connection to the control level is lost.
What Changes in Practice for Platform Teams?
Each data level can be linked to 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 routing 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.
Protection of secrets and keys is left to a store compatible with the External Secrets Operator or to a vault selected by the operating organization, rather than imposing default ownership of the keys. Fine-grained permissions can also be applied at the namespace, project, and component levels, 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 inside a shared host cluster, isolating control-plane state between tenants at a lower cost than dedicating a cluster to 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 give users direct access to sensitive clusters.
However, this combination has a clear limitation: tenants located on the same host share the node and the 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, 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. Creating a new jurisdiction then becomes a reviewable pull request, and answering why a tenant’s data exists in a particular region is based on a change log rather than a screenshot from a dashboard.
Nevertheless, a multi-level architecture does not change the legal jurisdiction of the organization 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 governing what happens within them; supply-chain attestation, SBOM, audit logging, and workload identity through tools such as SPIFFE/SPIRE remain separate controls that must be integrated.
Operational cost is the final constraint: every additional cluster requires monitoring, upgrades, and backups. Therefore, the architecture is justified when the boundaries drawn carry genuine legal or security significance, and may be excessive in environments that do not require them. 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 audited.