Skip to content

Architecture Overview

CloudTaser lets EU companies use US cloud providers (AWS, GCP, Azure) with cryptographic guarantees that neither the provider nor US government can access their data. It does this by keeping secrets out of Kubernetes storage entirely -- fetching them from EU-hosted vaults directly into process memory at runtime.

Components at a Glance

Component Repository Summary
Operator cloudtaser-operator Watches Kubernetes for annotated workloads and rewrites them to use the wrapper
Wrapper cloudtaser-wrapper Runs inside the application container, fetches secrets from the EU vault, and launches the app with secrets in memory
eBPF cloudtaser-ebpf Runs on every node and prevents any other process from extracting secrets from memory
S3 Proxy cloudtaser-s3-proxy Transparent client-side encryption proxy for S3-compatible object storage
Platform cloudtaser-platform SaaS control plane for managing, monitoring, and auditing CloudTaser across clusters
Helm cloudtaser-helm Packages everything into a single install command for Kubernetes
CLI cloudtaser-cli Command-line tool for deploying, validating, and troubleshooting CloudTaser
Docs cloudtaser-docs Product documentation, architecture decisions, and integration guides

Operator

The operator is the orchestrator. It prepares everything so that secrets can be delivered safely -- but it never touches the secrets themselves.

What it does:

  • Runs inside Kubernetes as a controller with a mutating admission webhook
  • Watches for workloads (pods) that carry CloudTaser annotations -- these annotations are how customers opt in
  • When a matching workload is created, the webhook intercepts the pod before it starts
  • Rewrites the pod's startup command so the wrapper binary runs first, before the application
  • Resolves the original container entrypoint automatically by querying the container registry, so customers do not need to specify their application's start command
  • Creates short-lived vault authentication tokens for the wrapper

What it does not do:

  • Does not fetch, store, or relay secrets. It only configures the injection mechanism
  • Does not modify application code or container images. It works with any existing image
  • Does not run inside the application container. It runs as its own deployment in the cluster

Wrapper

The wrapper is the secret delivery mechanism. It sits between the vault and the application, making sure secrets arrive safely in memory and stay fresh.

What it does:

  • Runs as PID 1 (the main process) inside the application container -- not as a separate sidecar container
  • Gets injected by the operator via an init container and an entrypoint rewrite
  • On startup: authenticates to the EU-hosted OpenBao/Vault, fetches the secrets the application needs
  • Maps vault secret fields to standard environment variable names (e.g., a vault field called password becomes PGPASSWORD)
  • Launches the original application command with those secrets available as environment variables. Zero code changes required
  • Stays alive as the parent process to handle vault token renewal and secret lease renewal
  • When secrets rotate: restarts the application with updated values, or sends a reload signal (SIGHUP) for applications that support it
  • Forwards shutdown signals (SIGTERM, etc.) to the application so it can exit gracefully
  • Nothing is written to disk. Secrets exist only in process memory

What it does not do:

  • Does not require any changes to the application
  • Does not persist secrets anywhere -- no files, no Kubernetes Secrets, no etcd
  • Does not decide which secrets to fetch -- that comes from the annotations the customer sets

:octicons-arrow-right-24: Wrapper Design

eBPF

The eBPF component is the enforcement layer. The wrapper delivers secrets into memory; eBPF makes sure nothing else can read them out.

What it does:

  • Runs as a DaemonSet -- one instance on every Kubernetes node
  • Operates at the kernel level to enforce security boundaries around protected processes
  • Blocks other processes from reading /proc/pid/environ (where environment variables, including secrets, are visible)
  • Blocks ptrace attach, preventing debuggers or memory inspection tools
  • Blocks core dumps, preventing secrets from being written to disk if the application crashes
  • Blocks /proc/pid/mem reads, preventing direct process memory inspection
  • Detects heap dump tools (jmap, gcore, etc.)

What it does not do:

  • Does not fetch, store, or manage secrets. It only protects what the wrapper has already delivered
  • Does not interfere with normal application behavior. It only restricts other processes from inspecting the protected one
  • Does not replace network-level security, encryption at rest, or access control -- it adds a runtime layer on top of those

Why it matters: Without eBPF, any process with sufficient permissions on the same node could read secrets from /proc. This is the gap that exists in every "inject secrets as environment variables" approach. eBPF closes it.

:octicons-arrow-right-24: Kernel Compatibility

S3 Proxy

The S3 proxy provides transparent client-side encryption for S3-compatible object storage (AWS S3, GCS via S3 API).

What it does:

  • Runs as a sidecar container alongside the workload
  • Intercepts S3 API calls on localhost:8190
  • Encrypts object bodies using envelope encryption: each object gets a unique data encryption key (DEK), wrapped by a key encryption key (KEK) in Vault Transit
  • Decrypts on read, re-signs requests with its own credentials, and forwards to the upstream S3 endpoint
  • The cloud provider stores only ciphertext. The KEK never leaves the EU vault

What it does not do:

  • Does not modify application code. The workload just points its S3 endpoint to localhost
  • Does not manage encryption keys directly. It delegates to Vault Transit
  • Does not support range requests on encrypted objects (due to the nature of AES-GCM)

:octicons-arrow-right-24: S3 Proxy Protocol

Platform

The platform is the management and visibility layer. It gives teams a centralized view of CloudTaser across all their clusters.

What it does:

  • Provides a SaaS control plane for managing CloudTaser deployments
  • Access management: defines who can access which secrets, with full audit trails
  • Observability: shows which workloads are protected, secret rotation status, and overall health
  • Policy management: sets rules for which namespaces and workloads should have injection enabled
  • Audit logging: records who accessed what and when, for compliance and regulatory reporting

What it does not do:

  • Does not run inside the customer's cluster. It connects to the operator for management but does not process secrets
  • Does not replace the vault. Secrets are still stored and served from the customer's EU-hosted vault

Helm

Helm charts are the packaging and installation mechanism.

What it does:

  • Packages the operator, eBPF daemonset, and configuration into Helm charts
  • Makes installation a single helm install command
  • Provides configurable values for vault address, namespace targeting, rotation policies, and other settings

CLI

The CLI is a command-line tool for operators and DevOps teams.

What it does:

  • Connects clusters to vault (Kubernetes auth configuration)
  • Discovers existing workloads using Kubernetes Secrets
  • Generates migration scripts from existing tools (ESO, Sealed Secrets, SOPS)
  • Validates vault connectivity and deployment health
  • Produces compliance audit reports
  • Generates NetworkPolicies

:octicons-arrow-right-24: CLI Reference

End-to-End Flow

Here is the complete flow when a workload is deployed with CloudTaser:

1. Customer annotates their workload

A team adds CloudTaser annotations to their Kubernetes deployment. These annotations specify which vault secrets the workload needs and how they map to environment variables. No other changes are required -- same container image, same application code.

2. Operator intercepts and rewrites

When Kubernetes creates the pod, the operator's webhook intercepts it. The operator queries the container registry to resolve the original entrypoint command, then rewrites the pod spec so the wrapper binary starts first. It also provisions a short-lived vault token for authentication.

3. Wrapper fetches secrets and launches the application

The wrapper starts as PID 1 inside the container. It authenticates to the EU-hosted vault, fetches the requested secrets, maps them to environment variables, and launches the original application command. The application starts up and reads its configuration from environment variables -- exactly as it would without CloudTaser. Secrets exist only in process memory.

4. eBPF protects secrets at runtime

On the node, the eBPF daemonset enforces kernel-level protections. No other process on the node can read the secrets from the protected process's memory or environment. This closes the gap that would otherwise allow a compromised neighbor or privileged process to extract secrets.

5. Platform provides visibility and control

Across all clusters, the platform shows which workloads are protected, tracks secret rotation, enforces policies, and maintains audit logs for compliance reporting.

The Key Insight

Traditional approaches store secrets in Kubernetes Secrets (etcd), which the cloud provider can access. CloudTaser never puts secrets into Kubernetes storage at all. The vault is in the EU, secrets travel directly into process memory, and eBPF ensures they cannot be extracted. The cloud provider never holds the keys.