## Understanding Cloud Sovereignty Through Platform Architecture
In modern cloud-native environments, **cloud sovereignty** has evolved beyond a simple question of *where* data is stored. Today, organizations must demonstrate *how* their platforms are operated, secured, and governed—especially under frameworks like the EU Data Act, NIS-2, DORA, and the UK Data Use and Access Act. A recent CNCF community post emphasized that compliance is not just about geographic regions, but about architectural boundaries—specifically, **where control and state live**, and **who can access them**.
OpenChoreo, an open-source CNCF Sandbox project, offers a practical example of how sovereignty can be embedded in platform architecture. Rather than treating sovereignty as a compliance checkbox, OpenChoreo treats it as a **property of the platform’s plane topology**, using a multi-plane design to enforce clear separation of responsibilities.
—
## Four Questions That Define Sovereignty
Most audit requirements can be distilled into four core questions:
1. **Jurisdiction:** For every component that can touch tenant data—including the control plane, logs, and metadata—can you name the legal jurisdiction it runs under?
2. **Operability:** If the vendor’s hosted service disappeared tomorrow, could your team continue operating, rebuilding, and moving the workload elsewhere?
3. **Access control:** Can anyone outside the boundary reach your keys, cluster state, or admin credentials?
4. **Portability:** If the provider, hardware, or country changes, does the workload move—or does it need to be rewritten?
These questions share a common theme: **location matters less than control and state**. That’s why a single shared Kubernetes cluster poses such a challenge—it consolidates control and state into a single point of failure and ambiguity.
—
## The Tenant-Cluster Pattern vs. Multi-Plane Architecture
The **tenant-cluster pattern** addresses this by giving each tenant its own control plane, providing strong isolation. But sovereignty demands more—platform-level control over placement, telemetry, promotion, and access policies. That’s where a **multi-plane topology** comes in.
OpenChoreo splits the platform into independent planes, each with its own lifecycle, scaling behavior, and security boundary:
– **Control Plane:** Holds desired state and runs reconciliation controllers—never tenant workloads.
– **Data Planes:** Run workloads as conformant Kubernetes clusters.
– **Observability Planes:** Collect logs, metrics, and traces.
– **Workflow Planes:** Execute CI/CD and GitOps operations.
– **Experience Plane:** Provides the developer portal, CLI, and API/MCP interfaces.
Importantly, **connections are outbound only**. Data, observability, and workflow planes connect *to* the control plane—but never the other way around. This design ensures:
– API servers hosting tenant workloads are never exposed to the internet.
– The control plane manages desired state, while data planes handle runtime execution.
– A data plane remains operational even if disconnected from the control plane.
—
## Answering Auditors Through Architecture
OpenChoreo’s multi-plane topology makes it possible to answer auditors with architecture rather than policy documents:
– **Jurisdiction:** By pairing one **data plane per jurisdiction**, tenant placement becomes architectural, not accidental. Observability planes are similarly regional, ensuring logs never leave the region.
– **Operability:** Each data plane is a full Kubernetes cluster built from open-source CNCF components—no vendor lock-in.
– **Access control:** Outbound-only mTLS keeps sensitive clusters unreachable from the internet. Secrets live in operator-chosen stores (e.g., Vault), and authorization is fine-grained, mapped from any OIDC provider.
– **Portability:** Workloads are declared as standard Kubernetes resources, enabling promotion across environments without rewrites. Moving workloads becomes a topology change, not a migration.
Even the **tenant-cluster pattern** benefits from this layering. Virtual clusters provide isolation, but the platform layer answers where telemetry goes, who can promote workloads, and how boundaries are enforced—all declaratively.
—
## FAQ
**Q: What is cloud sovereignty in the context of platform architecture?**
A: Cloud sovereignty refers to the ability to enforce data residency, operational control, and governance boundaries at the architectural level—not just through policy or location selection, but by designing platforms where control, state, and observability are isolated according to regulatory requirements.
**Q: Why does a shared Kubernetes cluster make sovereignty difficult?**
A: A shared cluster consolidates control plane components (API server, etcd, controllers) into a single surface. This makes it impossible to cleanly isolate tenants, assign jurisdictions, or audit who accessed what—key concerns for compliance.
**Q: What is the tenant-cluster pattern?**
A: It is an architecture where each tenant is allocated its own virtual cluster inside a shared host cluster, giving them a dedicated control plane and datastore. It provides strong isolation but does not solve platform-level concerns like regional placement or observability routing.
**Q: How does OpenChoreo ensure logs stay in-region?**
A: Through a dedicated regional observability plane. Each data plane sends telemetry to a region-local observability cluster, and queries are routed directly—without passing through a central control plane.
**Q: Are virtual clusters enough for sovereignty?**
A: No. Virtual clusters isolate tenants at the control plane level, but they don’t decide where data lives, where logs go, or how workloads move between regions. Those are platform-level decisions best handled by a multi-plane architecture.
**Q: Can workloads move between regions without being rewritten?**
A: Yes. Because workloads are expressed as standard Kubernetes resources, they can be promoted between data planes—whether in different regions, clouds, or on-prem environments—by changing the target `DataPlane` reference.
—
## Conclusion
Cloud sovereignty is no longer a checkbox—it’s an architectural requirement. As platforms like OpenChoreo demonstrate, **sovereignty is best expressed as a property of topology**, not location. By separating control, runtime, observability, and workflow into distinct planes, organizations can enforce boundaries that satisfy regulators, auditors, and operators alike.
The future of sovereign cloud-native platforms lies in **composable, declarative architectures**—where tenant isolation, regional boundaries, and audit trails are defined in code, managed through Git, and verified through deployment. In this model, sovereignty becomes less a promise and more a provable outcome of thoughtful design.
