Loading today’s stories
Product1 distinct publisher3 min readUpdated
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
Compiled by The Product DeskSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
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].
Ranked by verification strength, evidence, and original report placement.
Because the connection is outbound only, the API servers of clusters holding regulated workloads are never exposed to the internet; and because the control plane holds desired state rather than tenant runtime state, a data plane keeps serving traffic even if it loses its link to the control plane.
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.
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.
A single shared Kubernetes cluster makes the auditor questions hard to answer cleanly: one API server, one etcd, one set of controllers and admission webhooks serve every tenant, making it hard to point to a clear architectural boundary during an audit.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Single-source architectural argument, internally detailed but externally unverified
The cluster contains exactly one source, a CNCF blog post, and it is specific and self-consistent about mechanism: named planes, per-plane clusters, outbound mTLS to a control-plane gateway, desired-state-only control plane, conformant Kubernetes data planes. That earns credit for verifiable design detail on an inspectable open source project. It earns little beyond that: no independent reproduction, no security review, no disconnection or failover test, no legal or regulator citation behind the EU Data Act / NIS-2 / DORA / UK DUAA framing, and the supplied body is truncated mid-answer to Question 3.
Sandbox-stage reference implementation, no named users
The only adoption-adjacent facts supplied are that OpenChoreo sits at CNCF Sandbox maturity and that its own documentation describes the multi-regional pattern. No deployment, user, region count, customer, download or audit-completion figure appears anywhere in the source, and the wider pattern's uptake is not quantified. That places real-world traction near the floor without inferring anything the source does not say.
Moderately overstated: audit-defensibility asserted, operating cost unpriced
The post is hedged in useful ways — it says the ideas apply broadly, names the pattern as complementary to tenant clusters, and frames the connection model rather than the product as the sovereignty lever. But it leans on unvalidated conclusions: that a topology can be 'defended during an audit' is claimed by the advocating project and its own documentation, with no auditor, regulator or deployment confirming it, and the regulatory necessity framing carries no legal citation. Meanwhile the cost side is silent: a literal reading implies a five-cluster floor before any tenant lands and roughly seven for three jurisdictions, with nothing said about upgrade choreography or headcount. Overstatement is real but modest, not promotional.
Foundation blog showcasing a project in its own Sandbox
The publisher is CNCF and the worked example is OpenChoreo, a CNCF Sandbox project, with the supporting stack drawn largely from other CNCF projects (Argo Workflows, Cloud Native Buildpacks, Prometheus, OpenTelemetry, Flux, cert-manager, Cilium). The foundation therefore benefits when its hosted projects are read as the sovereignty-compliant path, and the post builds on an earlier community post in the same venue. Mitigating factors: the project is open source and inspectable, no pricing or vendor service is sold, and the post explicitly says the ideas generalise. Disclosure of author affiliation is not present in the supplied material.
Moderate-low: mechanism is checkable, outcomes are not
Confidence is limited by single-publisher sourcing, a truncated body, an unvalidated regulatory premise and zero adoption data, but supported by the fact that the architectural claims are concrete, attributable to an open source project, and internally coherent. The design description can be trusted as a description; the audit and compliance outcomes should not yet be treated as established.
build
Deleting kube-proxy moves your service traffic where your SIEM cannot follow it1 distinct publisher
build
Five pods green, GPU at 99 percent, queue up 70x: the Kubernetes dashboard is the wrong instrument1 distinct publisher
product
A hyperscaler reportedly handed Dutch regulators' emails to Congress. Residency was never sovereignty.1 distinct publisher
build
Thirteen tasks green, then "give up (Recommended)" on the one that needed understanding1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 18, 2026