Skip to content

EU Data Sovereignty for Kubernetes

Secrets never touch etcd. Cloud providers never hold the keys.

Start here - Sovereign Deployment Decision Guide

cloudtaser's cryptographic controls hold the sovereignty line only when two substrate decisions are made correctly: where OpenBao is hosted (US-parented providers silently break the claim) and which compute SKU runs your workload (commodity compute leaves the hypervisor-memory gap open). The guide below walks through the decision tree, names the silent-failure modes explicitly, and lists the substrate combinations that survive audit.

Sovereign Deployment Decision Guide - read before helm install. This is the load-bearing decision document for every cloudtaser deployment.

When cloudtaser is the right fit

You are a regulated EU team (financial services, healthcare, public sector, regulated SaaS) running on GKE / EKS / AKS who needs Schrems II supplementary-measures posture without re-platforming off the hyperscaler. cloudtaser delivers end-to-end sovereignty when you deploy with:

  • EU-sovereign OpenBao substrate - Hetzner, OVH, Scaleway, IONOS, Exoscale, UpCloud, SecNumCloud-qualified providers, or on-prem. Not AWS eu-central-1, GCP europe-west, or Azure North Europe (the CLOUD Act reaches the US parent regardless of region label).
  • Confidential-compute node SKUs with attestation - GKE c3d / n2d SEV-SNP, AKS DCdv5 / ECdv5, AWS Nitro Enclaves, or self-managed SEV-SNP / TDX / ARM CCA. This closes the hypervisor-memory gap; without it you get secrets-and-storage sovereignty but not data-in-use sovereignty.
  • Node kernels with CONFIG_BPF_KPROBE_OVERRIDE=y - GKE Ubuntu (linux-gke 6.8+), EKS AL2023, AKS Ubuntu 22.04+, AKS Azure Linux 3.0+, k3s on Ubuntu. Not available on GKE COS, EKS Bottlerocket, or Talos — those production-hardened distros ship with CONFIG_BPF_KPROBE_OVERRIDE=n and run on the LSM-hook path that ships with cloudtaser-ebpf#174. Without either path the eBPF layer degrades from synchronous block to reactive SIGKILL (the forbidden read has already returned bytes when the kill fires); the wrapper's dumpable=0 provides a synchronous baseline regardless. See Platform Compatibility for the full matrix.

With those three in place: the cryptographic boundary cloudtaser draws is defensible end-to-end and survives audit. Two-out-of-three is partial sovereignty - still a material posture improvement over K8s Secrets + SSE-S3, but your DPIA must reflect the gap honestly. The Sovereign Deployment Decision Guide names every failure mode explicitly; the Validation Roadmap dates the evidence we'll publish between now and Q3 2026 production-ready.

Not the right fit if: you can migrate to a SecNumCloud-qualified provider and the business tolerates it (that's often the cleaner path), you need self-managed Kubernetes (we're built for managed K8s), or you need existence-and-reference privacy on the control plane (pod manifests are visible to the provider's API server - outside our scope).

cloudtaser enables EU enterprises to run workloads on US-managed Kubernetes services (GKE, EKS, AKS) with cryptographic guarantees that neither the cloud provider nor any foreign government can access sensitive data. A mutating admission webhook rewrites container entrypoints to a fork+exec wrapper. The wrapper fetches secrets from an EU-hosted OpenBao (also compatible with HashiCorp Vault) instance directly into process memory via a beacon relay, bypassing Kubernetes Secrets and etcd entirely.

No secrets on disk. No secrets in the API server. Keys held in your EU-hosted OpenBao - see the Sovereign Deployment Decision Guide for the substrate choices that make the jurisdictional claim hold.

Three Layers of Protection

  • Injection -- Operator + Wrapper

    The cloudtaser operator watches for annotated pods and injects the wrapper binary via an init container. The wrapper authenticates to your EU-hosted OpenBao using Kubernetes service account tokens, fetches secrets, and launches your application with secrets available only in process memory.

    Getting Started

  • Encryption -- S3 Proxy

    A transparent client-side encryption proxy sits between your application and cloud object storage. Data is encrypted with keys held in your EU OpenBao before it ever reaches the provider. The cloud provider stores only ciphertext.

    S3 Proxy Installation

  • Enforcement -- eBPF Runtime

    A daemonset deploys eBPF programs on every node to enforce secret protection at the kernel level. 27 enforcement vectors (v0.4.8) detect and prevent secret leakage through file writes, network exfiltration, ptrace, core dumps, coredump redirect, namespace escape, and BPF tamper at runtime.

    eBPF Enforcement

How It Works

   EU Jurisdiction             Beacon Relay            US Cloud Provider
+----------------------+   +------------------+   +--------------------------+
|                      |   |                  |   |                          |
|  OpenBao             |   |  Stateless TCP   |   |  Managed Kubernetes      |
|  (secrets at rest)   |   |  relay on 443    |   |                          |
|       +              |-->|  Matches by      |<--|  Pod                     |
|  Bridge (outbound)   |   |  info_hash       |   |    wrapper (PID 1)       |
|                      |   |  Relays mTLS     |   |    (secrets in memory)   |
+----------------------+   +------------------+   |       |                  |
                                                  |    application           |
                                                  |                          |
                                                  |  etcd: no secrets        |
                                                  |  disk: no secrets        |
                                                  +--------------------------+

Secret delivery flow: Protected pod -> Operator broker -> Beacon relay -> Bridge -> EU OpenBao

Planning a deployment

Before installing, make two substrate decisions that the cryptographic controls alone cannot make for you: where OpenBao is hosted (the secret source of truth) and what compute SKU runs the target workload (whether runtime memory is hypervisor-sovereign). Getting either wrong silently undermines the sovereignty claim even while all CI checks pass.

Sovereign Deployment Decision Guide -- decision trees, provider comparison, scope breakdown, and silent-failure anti-patterns.

Trust boundary questions before you deploy

Three companion pages answer the questions a serious security or procurement reviewer will raise next:

  • Beacon Trust Model -- the beacon is customer-deployed infrastructure; this page documents what any beacon operator (i.e., you) can see, what is cryptographically invisible to the relay regardless of operator, and how the pattern eliminates inbound ingress on both your secret store and your cluster.
  • Preview Status & Roadmap -- the honest state of SOC 2, pentest, and reference customer work, with dated milestones.
  • Operational Readiness -- blast radius, failure modes, SLA, and the one-paragraph backout runbook.
  • Memory Isolation Landscape -- the full threat-model spectrum, what memfd_secret / eBPF / mlock cover, where confidential compute fits, and the deliberate scoping on SGX / Gramine / TME-MK / FHE.
Interactive Demo Try cloudtaser in a live Kubernetes cluster in your browser -- no signup required
Getting Started Deploy cloudtaser on GKE and protect your first workload in under 30 minutes
Sovereign Deployment Guide Pick the right OpenBao host and target compute SKU so the sovereignty claim holds
Beacon Relay Zero-config OpenBao connectivity -- both sides connect outbound to a stateless relay on TCP 443
Beacon Trust Model What cloudtaser, the company, sees -- jurisdictional posture, lawful-intercept exposure, self-hosting
Preview Status & Roadmap Dated audit milestones and honest gaps -- should you deploy today?
Operational Readiness Blast radius, failure modes, SLA, backout runbook
Installation Production installation for the operator, eBPF daemonset, and S3 proxy
Security Model Trust boundaries, threat model, and what cloudtaser does and does not protect against
CLI Reference cloudtaser-cli commands for deploy, discover, migrate, audit, and debug
Configuration Pod annotations, CRDs, and Helm values
Compliance Mapping to GDPR, NIS2, DORA, and Schrems II supplementary measures

Who Is This For

cloudtaser is built for EU enterprises running regulated workloads on managed Kubernetes. If your organization needs to:

  • Use US cloud providers (AWS, GCP, Azure) while maintaining EU data sovereignty
  • Comply with GDPR, NIS2, DORA, or Schrems II supplementary measures
  • Prove to auditors that secrets and sensitive data never leave EU jurisdiction
  • Eliminate Kubernetes Secrets and etcd as attack vectors

then cloudtaser provides the technical controls to make that possible.

Schrems II Supplementary Measures

The CJEU's Schrems II ruling (C-311/18) requires supplementary technical measures when transferring personal data to US cloud providers. Standard Contractual Clauses (SCCs) alone are insufficient. cloudtaser provides the technical primitives EDPB Recommendations 01/2020 lists as "effective supplementary technical measures" - client-side encryption with keys in customer-controlled OpenBao, secrets never in plaintext on provider infrastructure, runtime enforcement at the kernel layer. Whether a particular deployment satisfies Schrems II depends on substrate choices (OpenBao hosting, compute SKU, attestation posture) that the Sovereign Deployment Decision Guide walks through. The product gives you the artefacts auditors ask for; the deployment gives you the legal posture.

Primary target: financial services, healthcare, government, and regulated SaaS

cloudtaser is designed for organizations with 500--10,000 employees running production workloads on GKE, EKS, or AKS. Financial services is the initial focus, followed by healthcare, government, and B2B SaaS.