Sovereign by Design: Building a Sovereign Platform on Kubernetes

“Sovereign cloud” is the loudest phrase in European IT right now, and most of it is a sticker. Vendors slap it on a region, a contract clause, or a compliance certificate and call the platform sovereign. But sovereignty is not something you buy at the checkout — it is a property of how you architect. If it is not designed in, no label puts it there.

This is a practical, vendor-neutral architecture for building a genuinely sovereign platform. The core idea: stop treating sovereignty as one thing to procure, and start treating it as three independent layers you design for — with Kubernetes as the portability spine that ties them together.

This builds on a security foundation rather than replacing it. If your platform is not hardened first, sovereignty is moot — start from the secure-by-default GKE reference architecture and layer sovereignty on top.

Sovereignty Is Three Layers, Not One

The single biggest mistake is treating “sovereign” as a binary you either have or lack. It is really three separate questions, and a platform can score high on one while failing another.

• Data sovereignty — Where does the data physically live, and who can legally compel access to it? Residency is only half; the legal reach over the operator is the other half.
• Operational sovereignty — Who runs the control plane? Who can read, administer, or be compelled to expose the running system?
• Technical sovereignty — Can you leave? Are your workloads portable, or welded to one provider’s proprietary APIs?

A typical “sovereign cloud” offering covers one of these convincingly and waves at the rest. Real sovereignty means designing for all three — so let’s take them in the order that gives you the most leverage.

The Freedom to Leave: Portability as the Real Test

Technical sovereignty has a brutally simple test: what does it cost you to leave?

If leaving a provider means rewriting your applications and re-architecting around a different set of proprietary services, you are locked in — and lock-in is the exact opposite of sovereignty. If leaving means redeploying the same manifests onto a different conformant cluster, you are sovereign at the technical layer.

This is where Kubernetes earns its place — not as a container scheduler, but as the portability layer. Standard Kubernetes manifests, OCI images, Helm charts and infrastructure-as-code are conformant across every major platform and on-premises. The workload does not change when the ground underneath it does.

Portability is not free, though. The workload core travels; the edges do not — storage classes, ingress controllers, load-balancer annotations, and cloud identity integration are provider-specific and have to be abstracted or swapped deliberately. Real portability means keeping that core clean and the provider-specific edges thin and replaceable, not pretending nothing changes when you move.

The discipline is to keep your critical path on portable, standards-based components and to treat every proprietary managed service as a deliberate trade. A queue expressed as a Kubernetes workload moves anywhere; a queue that is a provider-specific API is an anchor.

# Portable: the workload is a standard object, not a vendor API.
# The same manifest runs on GKE, EKS, AKS, or an EU-hosted cluster.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingest
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: ingest
          image: registry.example.eu/ingest:1.8.0   # your registry, your region
          envFrom:
            - secretRef:
                name: ingest-config

Portability does not mean never using a managed service. It means knowing, for each one, exactly what leaving would cost — so “we could move” is a measured exit plan, not a comforting slogan.

Who Holds the Keys: Residency Is Not Custody

Here is the trap that sinks most “our data is in an EU region, so we’re sovereign” claims.

Data residency chooses where the bytes sit. It says nothing about who can read them. A provider operating under a foreign legal regime — the US CLOUD Act is the canonical example — can be compelled to hand over data regardless of which region it lives in. Residency alone does not stop that.

The control that actually changes the outcome is key custody. The pattern that truly delivers it is HYOK (hold your own key) — an external key manager such as Google’s External Key Manager (EKM) or AWS XKS, where the provider calls out to your key service to decrypt and never holds the key material itself. Plain BYOK, where you import a key into the provider’s own KMS, is weaker: the provider does hold the key, so it defends against a different and smaller threat. With true external custody:

• The provider stores your data encrypted, and ciphertext without your key is noise.
• If they are legally compelled to hand data over, what they can produce is that same worthless ciphertext.
• Revoke access to the key and new decryptions stop everywhere at once — already-cached data keys age out shortly after — which is effectively crypto-shredding the data.

Residency and key custody are complementary: residency answers “where,” custody answers “who can read it.” Custody is the one that turns a legal request into a non-event.

Keys are the whole game at the identity layer too. The same “no long-lived secret to seize” principle applies to workload credentials — see Kill Your Service Account Keys with Workload Identity Federation.

Operational Sovereignty: Who Can Read and Run It

The quietest layer is operational. Even with portable workloads and customer-held keys, sovereignty leaks if the people operating the plane can silently read or administer your systems from outside your jurisdiction.

Designing for operational sovereignty means:

• EU-only operations for regulated workloads — support and administration performed within the jurisdiction, not routed globally.
• Access transparency — every provider-side access to your environment is logged and visible to you, so “trust us” becomes “verify.”
• Least privilege and just-in-time access — no standing administrative access; elevation is scoped, time-boxed, and audited.
• Your own audit trail — logs shipped to storage you control, so the record of who did what does not depend on the provider’s goodwill.

None of this is exotic. It is the same access-control discipline you already apply to your own teams, extended to the provider as an untrusted operator.

Sovereignty Without Dogma: A Decision Framework

The failure mode on the other side is treating sovereignty as a purity test and paying a heavy velocity tax to make a marketing brochure with zero real workloads. Sovereignty is a spectrum, and you apply it by classification, not by reflex.

A pragmatic frame:

1. Classify the workload. Regulated or high-sensitivity data, or a system whose compromise is existential? It earns the full treatment: portable components, external key custody, operational controls. A stateless internal tool with no sensitive data? A convenient managed service is a perfectly rational trade.
2. Measure the lock-in, don’t assume it. For each proprietary dependency in the critical path, write down the real cost of leaving. Some are cheap to swap; some are anchors. You cannot manage what you have not measured.
3. Design the exit before you need it. Portability that has never been exercised is a hope, not a capability. Keep the option real: standard manifests, your own registry, keys you hold, infrastructure-as-code that can target a second platform.

Applied this way, sovereignty stops being a religious argument and becomes an engineering trade-off you make consciously, workload by workload.

The Honest Limits

Sovereignty has a cost, and pretending otherwise is how you end up resenting it. Portable, standards-based components sometimes mean giving up the slickest proprietary service. External key custody adds operational complexity and a failure mode of its own — lose the key and the data really is gone. Full operational sovereignty can raise support costs. And no architecture removes the legal reality that if you run on a provider at all, you are trusting something.

The point is not maximal sovereignty everywhere. It is that sovereignty becomes a property you designed on purpose — measured, classified, and exercised — instead of a sticker someone sold you. Build the three layers deliberately, keep the exit real, hold your own keys, and “sovereign” stops being a claim you hope survives scrutiny and becomes one you can actually demonstrate.