Use AWS, GCP, and Azure while keeping encryption keys under EU jurisdiction. The cloud provider stores only ciphertext.
EU companies face a fundamental conflict when using US cloud providers.
Under the US CLOUD Act (2018) and FISA Section 702, US authorities can compel any US-headquartered cloud provider to hand over data — regardless of where it's physically stored. The Schrems II ruling (CJEU, 2020) invalidated the EU-US Privacy Shield precisely because of this. Even data in EU regions on AWS, GCP, or Azure is subject to US jurisdiction. The provider holds the encryption keys, the database credentials, and the storage access. A single court order grants full read access to everything.
CloudTaser implements what the EDPB calls "effective supplementary technical measures" — the cloud provider physically cannot access your data in plaintext. Encryption keys live in an EU-hosted OpenBao (open-source Vault) instance under your control. Secrets are fetched into process memory at runtime. Object storage is encrypted client-side before upload. A court order yields only ciphertext and no keys to decrypt it.
/proc/environ reads and unauthorized network exfiltration of secrets
A cryptographic boundary between your data and the cloud provider.
Database passwords, API keys, and encryption keys are stored in an EU-hosted OpenBao (or HashiCorp Vault) instance — under your jurisdiction, not the cloud provider's. Secrets are fetched at pod startup directly into process memory using Kubernetes or token auth. They never appear in Kubernetes Secrets, etcd, ConfigMaps, or on disk. Lease renewal and token refresh happen automatically.
A mutating admission webhook intercepts pod creation and wraps the application process — not as a sidecar, but by rewriting the container entrypoint. The operator resolves the original image command from the container registry (OCI), injects an init container with the wrapper binary, and rewrites the command. Works with any image — scratch, distroless, alpine, or custom. No Dockerfile changes, no Helm template edits, no application code changes. Just add an annotation: cloudtaser.io/inject: "true".
An S3-compatible reverse proxy sits between your application and the storage endpoint (AWS S3, GCS, MinIO). It encrypts each object with a unique data encryption key (DEK) using AES-256-GCM, then wraps the DEK via the OpenBao Transit secret engine using a transient key — the plaintext DEK never persists. Your application points to the proxy instead of the provider endpoint. Decryption is automatic on download. The cloud provider only ever stores ciphertext.
A kernel-level eBPF agent runs as a DaemonSet and attaches tracepoints and kprobes to monitor secret access patterns. It detects when any process attempts to read /proc/pid/environ (where injected secrets live), when secret material appears in network write buffers, or when unexpected processes access protected memory. The wrapper registers its child PID with the eBPF agent, enabling container-to-host PID translation for accurate monitoring across namespaces.
Interactive demos running on real infrastructure. No signup required.
Each component handles one part of the sovereignty stack.
Mutating admission webhook that intercepts pod creation and injects the CloudTaser wrapper. Resolves original container entrypoints by querying the OCI registry (supports private registries with imagePullSecrets), rewrites the command to launch through the wrapper, and mounts a shared volume with the wrapper binary via an init container. Supports sealed/unsealed operation modes — in sealed mode, the operator brokers vault tokens so pods don't need direct vault credentials. Drop-in replacement for vault-agent-injector with zero sidecar overhead.
Process wrapper (similar to envconsul) that runs as PID 1 in the container, fetches secrets from your EU-hosted vault, injects them as environment variables, then execs the original application process. Secrets exist only in process memory — never on disk, never in tmpfs volumes (unlike vault-agent file-based injection). Supports Kubernetes auth and token auth. Handles automatic lease renewal and re-authentication. Registers child PIDs with the eBPF agent for runtime protection.
S3-compatible reverse proxy implementing envelope encryption. Each object gets a unique data encryption key (DEK) generated via OpenBao's Transit secret engine with transient keys — the plaintext DEK exists only in memory during the encryption operation. Objects are encrypted with AES-256-GCM before leaving the cluster. Compatible with any S3-compatible backend (AWS S3, GCS via interop, MinIO). Works with existing S3 SDKs — just change the endpoint URL. Supports multipart uploads and range reads.
Kernel-level monitoring using eBPF tracepoints and kprobes, deployed as a DaemonSet. Attaches to sys_enter_openat to detect /proc/pid/environ reads, monitors network write buffers for secret material exfiltration, and translates container PIDs to host PIDs for cross-namespace visibility. The wrapper registers each protected process with the agent at startup. Supports detection and enforcement modes — enforcement mode can block unauthorized access in real time.
Command-line tool for planning a migration to CloudTaser. Connects to your cluster, scans all pods and deployments for secret references (environment variables from Secrets, secretKeyRef, volume mounts), and generates a migration plan mapping each secret to a vault path. Helps estimate the scope of a rollout before you start — how many workloads use secrets, which namespaces are affected, and which secrets are shared across deployments.
Centralized management for access policies, audit logs, and observability across clusters. Web interface for managing vault connections, viewing secret access patterns, and configuring alerting.
Standard cloud encryption vs. client-side encryption with EU key sovereignty.
| Capability | Cloud-Native Encryption | CloudTaser |
|---|---|---|
| Provider sees plaintext | Yes — they hold the keys | No — ciphertext only |
| Keys under EU jurisdiction | Keys in provider KMS | EU-hosted OpenBao/Vault |
| CLOUD Act exposure | Provider can be compelled | No keys to surrender |
| Application changes | Varies by provider | None — annotation-based |
| Secret injection | vault-agent sidecar (extra container per pod) | Process wrapper (no sidecar, no resource overhead) |
| Secrets on disk | tmpfs volumes / etcd / K8s Secrets | Process memory only — never on disk |
| Object storage encryption | SSE — provider holds DEKs | Client-side AES-256-GCM, transient DEKs |
| Runtime secret protection | None | eBPF kernel-level monitoring |
| Secret rotation | Manual / provider-specific | Automatic via vault leases |
| Multi-cloud | Provider-specific APIs | Works on GKE, EKS, AKS — same Helm chart |