Use cloud responsibly
Use AWS, GCP, and Azure while keeping encryption keys under EU/UK jurisdiction. The cloud provider stores only ciphertext.
EU and UK 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 (12+ paths), ptrace, perf_event_open, io_uring, userfaultfd, and global privilege escalation detection
A cryptographic boundary between your data and the cloud provider.
Database passwords, API keys, and encryption keys are stored in an EU/UK-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 least-privilege DaemonSet with 20+ enforcement vectors. It blocks 12+ /proc paths (environ, mem, maps, smaps, syscall, stack, and more), ptrace attach, perf_event_open hardware watchpoints, io_uring async I/O bypass, and userfaultfd side-channel attacks. Global detection catches kernel module and eBPF program loading from any process. Secret values are stored using memfd_secret (physically removed from the kernel's direct memory map), locked in RAM with mlock, and excluded from core dumps. The wrapper communicates with the agent via Unix domain socket (no network attack surface), with PID pre-registration ensuring zero-gap monitoring from process start.
Other tools deliver secrets to memory and stop there. CloudTaser makes secrets invisible to the kernel itself.
Vault Agent, External Secrets Operator, SOPS, and AWS Secrets Manager all write secrets into regular process memory. Once delivered:
/proc/pid/mem by anyone with root — including the cloud provider
ptrace attach — standard debugger techniques
Secrets are stored using Linux kernel primitives designed for sensitive data, protected by 20+ eBPF enforcement vectors. No other Kubernetes tool does this.
memfd_secret(2) — physically removes secret pages from the kernel's direct memory map. Not even the kernel can read them.
mlock(2) — locks secret pages in RAM. Fail-fast mode refuses to start if mlock is unavailable.
PR_SET_DUMPABLE. Crash reports contain no credentials.
/proc paths, ptrace, perf_event_open, io_uring, and userfaultfd on protected processes.
memfd_secret(2) (Linux 5.14+) provides hardware-level memory isolation — secret pages are physically removed from the kernel's direct memory map. Combined with 20+ eBPF enforcement vectors blocking /proc, ptrace, perf_event_open, io_uring, userfaultfd, and global privilege escalation detection, CloudTaser provides the most comprehensive runtime secret protection available. No other Kubernetes secret management tool provides this level of in-memory protection.
Secure your existing infrastructure without rebuilding it.
CloudTaser wraps your existing processes transparently. Your application doesn't need to know how to talk to a vault — the wrapper fetches secrets and injects them as environment variables before your app starts. Works with any image: scratch, distroless, alpine, legacy Java apps, off-the-shelf containers. If it reads environment variables, it works.
Unlike vault-agent-injector which runs a sidecar container per pod (extra CPU, memory, and startup latency), CloudTaser uses a process wrapper — no additional containers, no persistent processes. The init container copies a single static binary and exits. The wrapper execs your application directly. Resource consumption is effectively zero.
The CloudTaser CLI scans your cluster and maps every secret reference: secretKeyRef in env vars, secret volume mounts, ConfigMap references. It tells you exactly which workloads use secrets, which namespaces are affected, and generates vault path mappings — so you know the full scope before changing a single annotation.
Applications that were never designed for vault integration — legacy services, third-party containers, off-the-shelf databases, monitoring stacks — all work out of the box. The operator auto-detects the container entrypoint from the OCI registry. No Vault SDK, no vault-agent config files, no template rendering. Just annotate and deploy.
Interactive demos running on real infrastructure. No signup required.
Preview release — install via Helm from GitHub Container Registry.
helm pull oci://ghcr.io/skipopsltd/cloudtaser-helm/cloudtaser --version 0.1.20helm upgrade --install cloudtaser cloudtaser-0.1.20.tgz \
--namespace cloudtaser-system --create-namespace \
--set operator.vaultAddress="https://vault.eu.example.com"kubectl patch deployment my-app -p '{
"spec": {"template": {"metadata": {"annotations": {
"cloudtaser.io/inject": "true",
"cloudtaser.io/vault-address": "https://vault.eu.example.com",
"cloudtaser.io/vault-role": "my-app",
"cloudtaser.io/secret-paths": "secret/data/db/credentials",
"cloudtaser.io/env-map": "password=DB_PASSWORD"
}}}}
}'| Component | Image |
|---|---|
| Operator | ghcr.io/skipopsltd/cloudtaser-operator |
| Wrapper | ghcr.io/skipopsltd/cloudtaser-wrapper |
| S3 Proxy | ghcr.io/skipopsltd/cloudtaser-s3-proxy |
| eBPF Agent | ghcr.io/skipopsltd/cloudtaser-ebpf |
| Helm Chart | ghcr.io/skipopsltd/cloudtaser-helm/cloudtaser |
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 with mandatory mTLS on the unseal endpoint. Handles automatic lease renewal and re-authentication. Pre-registers child PIDs with the eBPF agent via Unix domain socket for zero-gap runtime protection. Vault tokens protected with mlock; fail-fast mode refuses to start if mlock is unavailable.
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 enforcement using 20+ eBPF tracepoints and kprobes, deployed as a least-privilege DaemonSet (explicit capabilities, no privileged mode). Blocks 12+ /proc paths, ptrace, perf_event_open hardware watchpoints, io_uring async I/O bypass, and userfaultfd side-channels on protected processes. Global detection catches kernel module and eBPF program loading from any process. Communicates with the wrapper via Unix domain socket (no network attack surface). The wrapper pre-registers PIDs with fork auto-tracking for zero-gap monitoring. Vault tokens protected with mlock across all components.
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/UK jurisdiction | Keys in provider KMS | EU/UK-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 | 20+ eBPF vectors: /proc, ptrace, perf_event_open, io_uring, userfaultfd |
| Secret memory protection | None | memfd_secret + mlock + no core dumps |
| Secret rotation | Manual / provider-specific | Automatic via vault leases |
| Multi-cloud | Provider-specific APIs | Works on GKE, EKS, AKS — same Helm chart |