Digital Sovereignty with Kubernetes: When Is Open Source Truly Sovereign?

Kubernetes was created by Google. Yet European companies and government agencies use it as the foundation for their sovereign cloud strategy. This is not a contradiction, if you understand which dimension of sovereignty really matters.

The debate often revolves around the wrong question. The relevant question is not "Was the code written in the EU?" but rather: "Who controls access to my data and systems at runtime?" This article explains the difference, why it matters in practice, and what Kubernetes has to do with it.

What digital sovereignty actually means

The term is widely used but rarely clearly defined. In the context of cloud infrastructure, three dimensions can be distinguished:

• Data sovereignty: Control over where data resides, who can access it, and how it is processed. For a detailed breakdown of why data residency differs from data sovereignty, see our dedicated analysis.
• Operational sovereignty: Control over platform operations (admin access, updates, incident handling, key management).
• Legal immunity: Protection through applicable law and jurisdiction (e.g., EU/German law, protection against extraterritorial access claims).

These three dimensions are related but not identical. A tool can be strong in dimension three while simultaneously failing in dimension one or two, depending on how it is deployed.

In a previous blog post, we described the Cloud Sovereignty Framework, where data sovereignty, operational sovereignty, legal immunity, and how sovereignty is defined and measured play a central role. You can find it in our Cloud Sovereignty Framework article.

Kubernetes and its roots at Google

Google released Kubernetes as an open-source project in 2014, based on internal systems like Borg. In 2016, the project was handed over to the Cloud Native Computing Foundation (CNCF), which is part of the Linux Foundation. Today, Kubernetes is one of the most active open-source projects worldwide, with maintainers from dozens of companies and organizations.

The code is licensed under the Apache 2.0 license, one of the most permissive open-source licenses available. This means any organization can use, modify, distribute, and commercially deploy Kubernetes without paying license fees or being required to contribute source code back.

The CNCF as a governance model

What many don't know: Google no longer has formal veto power over the direction of Kubernetes. CNCF governance regulates how decisions are made. The Kubernetes Steering Committee and the Technical Oversight Committee are composed of members from various companies. No single corporation determines the roadmap.

This is a relevant characteristic for sovereignty questions because it means the continuity and development of the project are not tied to the fate of a single company.

Open source as a sovereignty factor, but not the sole deciding one

Open-source code offers real advantages for digital sovereignty: The code is auditable. Security vulnerabilities can be found and reported by the community. There is no vendor lock-in at the license level. Anyone who wants to can fork.

Yet open source is not a free pass. The decisive question is not where the code comes from, but where it runs.

The crucial distinction: Where does the code run?

A Kubernetes cluster running on AWS, GCP, or Azure in a US region is subject to US law, even if Kubernetes itself is open source. The CLOUD Act of 2018 obliges US companies, under certain circumstances, to grant authorities access to data, regardless of where that data is physically stored.

This means: Running Kubernetes on a US hyperscaler may leave a gap in data sovereignty, not because of Kubernetes, but because of the operating model.

Turn it around: Kubernetes, operated on your own hardware or in an EU data center by a European provider, with no contractual relationship to a US company, is a substantially different starting point.

Digital sovereignty with Kubernetes in practice

What does this mean for architecture decisions? Some guidelines that make the difference in practice:

Location of operations: Kubernetes clusters should run in data centers that are exclusively subject to EU law. ISO 27001 certification and no parent company in the US are sensible minimum requirements.

Managed vs. self-managed: Running Kubernetes yourself gives maximum control but carries the operational burden. Managed Kubernetes offerings from European providers can be a good balance, provided the operators meet the requirements mentioned above.

Supply chain: Which container images, Helm charts, and operator deployments are being used? Here too: open source is more auditable than proprietary software, but it is no automatic guarantee of security.

The CLOUD Act and its implications

The Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 2018) allows US authorities to demand that US companies hand over data stored outside the United States. This directly affects AWS, Microsoft, Google, and other hyperscalers.

For European organizations processing sensitive data, such as health data, government data, or data subject to NIS2 or GDPR, this is a real risk. It has nothing to do with whether Kubernetes is open source or not. It is about who holds the operating contract.

When is Kubernetes truly sovereign?

A pragmatic checklist for teams that want to clarify this question for their organization:

• Operator: Is the operator a company headquartered exclusively in the EU, with no US parent company?
• Data center: Is the infrastructure located in an EU data center that is exclusively subject to EU law?
• Contractual situation: Are there no contractual relationships that could enable US authorities to access data?
• Auditability: Are only open-source components used whose code is publicly accessible?
• Portability: Is the architecture designed so that switching operators is possible without data loss?

If you can answer yes to all five points, you are running Kubernetes sovereignly, regardless of the fact that the code originally came from Google.

The origin of the code is a question of history. Control over operations is a question of the present.

If you want to run Kubernetes in a sovereign environment without the effort of fully self-managed operations, lowcloud is the right choice: a Kubernetes-based PaaS, operated exclusively in German data centers under EU law. No US hyperscaler, no dependencies that undermine operational sovereignty.