Product1 publisher3 min readPublished
Sovereignty audits are moving from the region picker to the plane topology
A CNCF post argues the EU Data Act, NIS-2, DORA and the UK DUAA force platform teams to show isolation across control, runtime, build and observability planes, not just a region.
The Product Desk · Product desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- A CNCF blog post argues that sovereignty conversations often start with regions (where a workload runs and where its data is stored), but that the architecture of the platform matters just as much, particularly how it separates control, runtime, build and observability responsibilities across clusters.
- 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 must show how the platform is operated, secured and governed, all the way down to the control plane.
- An earlier CNCF community post, "From data residency to digital sovereignty: architectural patterns for cloud native platforms," laid out the requirements and introduced the tenant-cluster pattern as one way to draw isolation boundaries.
- The post restates the regulatory requirements as four questions auditors or procurement teams ask: (1) for every component that can touch tenant data, including the control plane and surrounding logs and metadata, can you name the legal jurisdiction it runs under; (2) if the vendor's hosted service disappeared tomorrow, could the team continue operating the workload, rebuild it and move it elsewhere; (3) can anyone outside the boundary reach your keys, cluster state or an admin credential; (4) if the provider, hardware or country changes, does the workload move or does it need to be rewritten.
- The post observes that almost none of the four questions are about location; they are about where control and state live, and who can reach them.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
A post on the CNCF blog argues that the cloud sovereignty conversation has been fixed on the wrong variable: teams start with where a workload runs and where its data is stored, when the more consequential question is how the platform separates control, runtime, build and observability responsibilities across clusters [1]. The reason that matters operationally is regulatory: under the EU Data Act, NIS-2, DORA and the UK Data Use and Access Act, the post says platform teams now have to show how the platform is operated, secured and governed all the way down to the control plane, not only where workloads run [2].
The most portable part of the argument is its translation of compliance language into four questions an auditor or procurement team actually asks: 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 the vendor's hosted service disappeared tomorrow, could you keep operating the workload, rebuild it and move it; can anyone outside the boundary reach your keys, cluster state or an admin credential; and if the provider, hardware or country changes, does the workload move or does it get rewritten [4]. As the post notes, almost none of these are about location. They are about where control and state live, and who can reach them [5].
That is where a single shared Kubernetes cluster gets awkward. One API server, one etcd, one set of controllers and admission webhooks serve every tenant, which leaves nothing clean to point at during an audit [6]. An earlier CNCF community post proposed the tenant-cluster pattern, giving each boundary its own control plane [3][7]. The new post pushes the same logic one layer up, using OpenChoreo, an open source internal developer platform and CNCF Sandbox project, as an inspectable example, and says the two patterns compose [8][15].
The topology splits the platform into a control plane holding desired state and running reconciliation controllers but no tenant workloads [10], one or more data planes that are conformant Kubernetes clusters with their own API servers and state [11], plus observability, workflow and experience planes, each its own cluster with its own lifecycle, scaling and security boundary [9]. The detail that carries the audit argument is the direction of the connections: data, observability and workflow planes each dial out to the control plane's gateway over mutual TLS, and the control plane never dials in [12]. Two consequences follow. The API servers of the clusters holding regulated workloads are never exposed to the internet, and because the control plane holds desired state rather than runtime state, a data plane keeps serving traffic when the link to the control plane drops [13]. Jurisdiction then becomes a mapping rather than an essay: one jurisdiction, one data plane [14].
The bill for this is cluster count. Taken literally, the topology needs at least five clusters before any tenant is onboarded [1], and a platform serving three jurisdictions under the one-jurisdiction-one-data-plane rule needs at least seven [2]. That is the trade an operator is actually being offered: more clusters to run, in exchange for boundaries that survive a question about admin credentials.
Worth watching whether auditors and procurement teams accept plane topology as evidence, since the post supplies the architecture but no regulator or auditor saying it clears a specific control [4]. Also worth watching how the second question lands, since escapability from a hosted service is a test of the build and observability planes as much as the runtime one [4].