Kubernetes Sovereignty: No Vendor, No Foreign Dependency

Your Kubernetes cluster runs every containerized workload, stores every secret, and orchestrates every deployment. The sovereignty of your platform determines the sovereignty of everything running on it.

Hyperscaler Kubernetes services (GKE, EKS, AKS) bundle the open-source Kubernetes core with proprietary control planes, identity systems, and networking layers — all operated by US companies under US law. Even "Swiss region" deployments are subject to the CLOUD Act, meaning a US court can compel access to your cluster data without Swiss judicial process. Managed OpenShift adds Red Hat (IBM subsidiary, US) as an additional dependency in the corporate chain.

Vanilla Kubernetes — the CNCF-governed open-source project — has no corporate owner, no proprietary extensions, and no license restrictions. VSHN operates managed Kubernetes on Swiss infrastructure with zero non-Swiss vendor dependencies.

Why vanilla Kubernetes maximizes sovereignty

Compared to any managed Kubernetes offering from a hyperscaler or vendor distribution, vanilla Kubernetes eliminates every foreign dependency:

• No corporate owner — governed by the CNCF (Linux Foundation), not a single company
• No proprietary control plane — the entire stack is open source and auditable
• No vendor subscription — unlike OpenShift (Red Hat/IBM), no commercial license or certified image registry required
• No platform lock-in — standard Kubernetes APIs, portable to any infrastructure
• No foreign dependency — VSHN builds and operates the platform with no US corporate chain at any layer

This is the key difference from managed OpenShift: with vanilla Kubernetes, there is no Red Hat subscription, no IBM corporate parent, no foreign entity providing certified images or update channels. The dependency chain is entirely Swiss.

Managed Kubernetes sovereignty compared

The zero-dependency argument

Every managed Kubernetes offering except vanilla K8s introduces at least one foreign dependency:

• GKE — requires Google Cloud account, Google-specific node pools, Google IAM
• EKS — requires AWS account, AWS-specific networking (VPC CNI), AWS IAM
• AKS — requires Azure account, Azure-specific networking, Azure AD integration
• Managed OpenShift — requires Red Hat subscription, Red Hat-certified images, Red Hat update channels

With VSHN Managed Kubernetes, the dependency chain is:

1. Kubernetes — CNCF-governed, open source (Apache 2.0)
2. Infrastructure — Swiss providers (cloudscale.ch, Exoscale) or customer-owned
3. Operations — VSHN AG (Swiss-owned, Swiss-operated)
4. Application services — VSHN Application Catalog, all open source, all on the same sovereign stack

No foreign corporation appears anywhere in this chain. This is what maximum Kubernetes sovereignty looks like.

VSHN sovereignty self-assessment

We applied the EU's Cloud Sovereignty Framework (v1.2.1, October 2025) to our own services. This framework was used to score providers in the EU's EUR 180M sovereign cloud tender in April 2026 — three pure-European providers achieved SEAL-3, while a consortium involving Google Cloud scored only SEAL-2.

This is a self-assessment, not a formal SEAL certification. We publish it for transparency so customers can evaluate our sovereignty profile using the same structured criteria the EU uses.

Overall: SEAL-3 equivalent — the same level achieved by the winners of the EU's own sovereignty tender. No provider worldwide achieved SEAL-4, as it requires fully EU/EEA-sourced hardware supply chains and open-source foundations — structural gaps shared by every cloud provider.

Get a sovereignty assessment for your Kubernetes setup

Running Kubernetes on a hyperscaler and concerned about CLOUD Act exposure? We assess your sovereignty profile against the EU framework and plan a migration to vanilla Kubernetes on Swiss infrastructure with zero non-Swiss vendor dependencies.