---
title: "Sovereign by Design: Building a Sovereign Platform on Kubernetes"
description: "A practical 2026 architecture for digital sovereignty: treat sovereign cloud as three layers — data, operational, technical — and use Kubernetes, external key custody, and a real exit path to make sovereignty a design property instead of a marketing sticker."
author: Aleksei Aleinikov
date: 2026-07-12
lang: en
tags: [sovereign-cloud, digital-sovereignty, kubernetes, data-residency, key-management, platform-engineering, vendor-lock-in]
canonical: https://www.alekseialeinikov.com/en/blog/topics/architecture/sovereign-by-design-building-a-sovereign-platform-on-kubernetes-2026
source: alekseialeinikov.com
---

# 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](https://www.alekseialeinikov.com/en/blog/topics/architecture/secure-by-default-gke-reference-architecture-2026) 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.

![The three layers of sovereignty — data residency and access, operational control, and technical portability — and what keeps each one yours.](https://www.alekseialeinikov.com/blog/sovereignty-three-layers-2026.webp)

- **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.

![Portability as the freedom to leave: proprietary services force a rewrite, while Kubernetes manifests redeploy unchanged across GKE, EKS, AKS or an EU-hosted cluster.](https://www.alekseialeinikov.com/blog/sovereignty-kubernetes-portability-2026.webp)

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.

```yaml
# 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.

![Key custody vs the CLOUD Act: when you hold the keys in an external manager, the provider stores only ciphertext and legal reach yields nothing readable.](https://www.alekseialeinikov.com/blog/sovereignty-key-custody-2026.webp)

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](https://www.alekseialeinikov.com/en/blog/topics/security/kill-service-account-keys-workload-identity-federation-2026).

## 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.