Skip to content

EU Data Sovereignty for Kubernetes

Secrets never touch etcd. You keep the keys in your own EU store.

Limits: Authorised apps can disclose copied or encoded secrets. Direct mode allows another workload using the same identity to read permitted records; on Port, denial of a second same-identity workload is unproven. Use one workload per identity; see the security model.

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 n2d Milan SEV-SNP / c3 TDX, 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.
  • A qualified node kernel with active BPF LSM and CONFIG_BPF_KPROBE_OVERRIDE=y - check the exact image and runtime evidence. The measured GKE Ubuntu 6.8.0-1062-gke has kprobe override but no active bpf LSM, so the default requireLSM gate refuses startup; the Ubuntu name alone does not establish support on GKE, AKS or k3s. Not available on GKE COS, AKS Azure Linux 3.0, Debian 12/13 or Talos, and unverified on EKS AL2023 — check the node. On a kernel without it, BPF LSM hooks cover only some vectors and reactive SIGKILL acts after the forbidden read has returned bytes, so the default chart's agent is not ready and protected workloads are refused. 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 controls that reduce specific secret-delivery and runtime access risks. Confidentiality depends on the identity, application, node and compute boundaries below. 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. 37 catalogued kprobe syscall programs cover specific runtime paths. Verify each required vector's actual state; detection, reactive termination and synchronous denial have different outcomes. These controls do not guarantee that an authorised app cannot transmit copied or encoded secrets.

    eBPF Enforcement

How It Works

   EU Jurisdiction               Beacon Relay                  US Cloud Provider
+----------------------+   +----------------------+   +----------------------------+
|  OpenBao             |   |  Stateful TCP relay  |   |  Managed Kubernetes        |
|  (secrets at rest)   |   |  on port 443         |   |                            |
|  +                   |-->|  Matches by info_hash|<--|  Pod                       |
|  Port (outbound)     |   |  Relays mTLS         |   |    wrapper (PID 1)         |
|                      |   |                      |   |    secrets in memory       |
|                      |   |                      |   |    application             |
|                      |   |                      |   |    etcd: workload specs    |
|                      |   |                      |   |    disk: see security model|
+----------------------+   +----------------------+   +----------------------------+

Secret delivery flow: Protected pod -> Operator broker -> Beacon relay -> Port -> 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.
Demo Status Hosted demo offline until beta; see historical architecture and self-hosted evaluation options
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 Customer-selected relay and tenant setup; both sides connect outbound 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.