데이터 주권에서 디지털 주권까지: 클라우드 네이티브 플랫폼의 아키텍처 패턴

Source: CNCF 블로그

2026년 6월 16일 게시 | Hrittik Roy, CNCF 대사

---

CNCF 프로젝트 하이라이트

Over the past two years, digital sovereignty has evolved from a policy discussion into a practical platform engineering concern. The EU Data Act has been fully applicable since January 11, 2025. NIS-2 and DORA already shape day-to-day platform decisions across regulated sectors, and the UK Data Use and Access Act 2025 is rolling out through 2026 with portability rules that bite.

As a result, platform teams are increasingly being asked to demonstrate not only where workloads run, but also how infrastructure is operated, secured, and governed. Questions about control planes, encryption keys, administrative access, auditability, and workload portability now appear alongside traditional data residency requirements.

For organizations building cloud native platforms, this raises an important architectural challenge. While regional infrastructure remains an important consideration, many sovereignty requirements ultimately depend on how control, access, and operational responsibility are distributed throughout the platform stack.

This article explores how Kubernetes-based platforms can address those requirements, and why control-plane design is becoming an increasingly important part of the sovereignty conversation.

‘주권’이 실제 플랫폼에 요구하는 것

When you decompose what regulators, auditors, and procurement teams keep asking for, four properties show up repeatedly:

• 지역적 관할권. Every component that can read tenant data, including the control plane, runs under a legal jurisdiction the organization can name and defend.

• 운영 자율성. The team that runs the workload can rebuild, migrate, and audit it without depending on a single vendor’s hosted services.

• 암호화 및 액세스 제어. Keys, etcd contents, and admin credentials are not accessible to an entity outside the chosen jurisdiction.

• 이식 가능. If the underlying hardware, provider, or country has to change, the workload moves without rewrite.

For sovereign cloud builders, these are not just regulatory boxes. Control plane location, metadata storage, administrative access, encryption, and key management ownership all have to be explicitly defined, alongside backup strategies and support access models that respect the jurisdictional boundary. None of this is satisfied by “we picked Frankfurt.” It is satisfied by infrastructure choices that go all the way down to the control plane.

Why a single Kubernetes cluster falls short

When building a sovereign platform, these requirements quickly become unavoidable, with Kubernetes serving as the foundational centerpiece that brings them together and provides the right substrate for sovereign platforms. CNCF backing, declarative APIs, and an open ecosystem (Kyverno for policy, Argo CD and Flux for GitOps, KubeVirt for VMs, Cilium for networking, SPIFFE/Spire for workload identity) are exactly the building blocks local regulated enterprises are converging on. The Swisscom sovereign Kubernetes reference architecture published on architecture.cncf.io is a clear signal of where the industry is heading.

The moment you start mapping real sovereignty requirements onto a single cluster, the gaps appear:

• One control plane serves all tenants. A jurisdictional incident affecting one tenant’s data plane risks affecting everyone sharing the API server, etcd, and controllers.

• Namespaces are not isolated. Even with strong RBAC, CRDs are shared, admission webhooks are shared, and a misconfigured controller leaks across the cluster.

• Cluster sprawl is the usual fallback. A full Kubernetes cluster per jurisdiction, per environment, per team. Operationally heavy, expensive, and slow to change.

In practice, operators often run shared platforms that support multiple regulated environments simultaneously, each with its own operational, compliance, and residency requirements.

For example, a provider may operate separate EU and UK tenant environments, each backed by its own regional infrastructure, storage, and audit boundaries like below:

Pic: Sovereign Design, which isn’ t Sovereign ( From* Sovereign: What It Means** )*

The challenge with the above is that workload placement alone does not establish sovereignty. Even if tenant workloads run in separate regions, a shared Kubernetes control plane still centralizes administrative authority, policy enforcement, APIs, controllers, and key operational decisions. Wherever that control plane resides and whoever governs it ultimately defines the platform’s real sovereignty boundary.

Tenant clusters as a sovereignty primitive

The pattern worth learning here is the tenant cluster: a Kubernetes control plane carved out for a single isolation boundary, running on top of a shared underlying cluster. Each tenant cluster has its own API server, its own controller manager, its own scheduler, and its own data store. From the workload’s perspective, it is talking to a real, conformant Kubernetes cluster. From the platform’s perspective, the tenant cluster’s control plane runs as a set of pods on a shared Control Plane Cluster.

One popular way to implement this pattern is vCluster, an open source project that provisions tenant clusters as pods inside an existing Kubernetes cluster. We will use it as the running example for the rest of this post because it is easy to try locally, but the architectural ideas apply to anything that gives each isolation boundary its own control plane.

A few properties of tenant clusters matter directly for sovereignty.

Independent control planes. Each tenant cluster has its own API server and its own backing store (embedded etcd, external etcd, or a SQL database). One tenant’s CRDs, admission webhooks, and audit logs do not bleed into another’s. Separate control planes also mean separate Kubernetes versions, separate upgrade cycles, and variation in the platform stack per tenant, which becomes important the more tenants you have. A jurisdictional boundary at the cluster level becomes meaningful.

Pluggable backing store. The tenant cluster’s state can live on encrypted volumes on hardware you own, under the operator you choose. State residency, not just workload residency, becomes something you can design.

Tenant isolation, not multi-tenant namespaces. Workloads inside a tenant cluster cannot reach back into the underlying cluster’s API. For stronger runtime isolation at the container layer, a common approach is to pair the tenant cluster with a user‑namespace based runtime such as vNode, or with gVisor or Kata Containers where a VM boundary is required. This matters for AI cloud operators in particular, where the threat model usually combines container‑escape concerns with the need to keep ten