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 OpenBaos directly into process memory at runtime.

Components at a Glance¶

Component	Repository	Summary
Operator	`cloudtaser-operator`	Mutating admission webhook, broker, beacon connector, DebugReport controller
Wrapper	`cloudtaser-wrapper`	Fork+exec secret delivery with memfd_secret, optional LD_PRELOAD interposer (glibc-only), and in-memory protection
eBPF	`cloudtaser-ebpf`	35 enforcement vectors at the kernel level, Unix socket communication with wrapper
Bridge	`cloudtaser-onprem`	Runs alongside OpenBao, outbound-only connection, cert auto-reload, admin proxy for remote management
Beacon	`cloudtaser-beacon`	Stateless TCP relay on port 443, SHA-256 info hash discovery, zero state
CLI	`cloudtaser-cli`	Full lifecycle tool: deploy, discover, migrate, audit, debug, fingerprint, register
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
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
Runs a broker that accepts connections from wrappers and tunnels secret requests through the beacon relay to the bridge
Manages beacon connectivity -- connects outbound to the beacon relay for OpenBao communication
Provides a DebugReport controller -- creates diagnostic reports via the DebugReport CRD for troubleshooting injection and connectivity issues
Stores all operational secrets (webhook TLS certs, broker tokens) in OpenBao, not Kubernetes Secrets

What it does not do:

Does not fetch, store, or relay secrets. It only configures the injection mechanism and proxies requests
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 OpenBao 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, fetches the secrets the application needs
Maps OpenBao secret fields to standard environment variable names (e.g., an OpenBao 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 OpenBao 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

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.

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 OpenBao 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 OpenBao

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 OpenBao Transit
Does not support range requests on encrypted objects (due to the nature of AES-GCM)

S3 Proxy Protocol

Bridge¶

The bridge runs alongside the EU OpenBao and provides outbound-only connectivity to the beacon relay.

What it does:

Connects outbound to the beacon relay on TCP 443 -- no inbound ports on the OpenBao server
Receives secret requests from the operator broker through the relay
Validates pod JWTs using locally cached JWKS keys
Fetches requested secrets from the local OpenBao instance
Returns secret data through the encrypted relay tunnel
Provides an admin proxy for remote OpenBao management -- forwards arbitrary OpenBao API calls through the bridge for CLI operations like target migrate
Authenticates admin proxy requests with its own OpenBao token when the caller does not provide one -- eliminates the need for provisioner tokens
Supports certificate auto-reload from OpenBao -- bridge detects cert changes and reloads without restart
Uses mTLS for broker authentication and heartbeat-based connection health monitoring

What it does not do:

Does not store secrets. It proxies requests between the relay and the local OpenBao
Does not require inbound ports. It connects outbound only
Does not make decisions about secret access. OpenBao RBAC policies apply per-pod

Beacon¶

The beacon is a stateless TCP relay that connects the bridge (OpenBao side) and broker (cluster side).

What it does:

Accepts TLS connections on port 443 from both bridge and broker
Matches connections by SHA-256 info hash (derived from the bridge CA certificate)
Relays encrypted bytes bidirectionally between matched pairs
Holds zero state -- no secrets, no keys, no configuration

What it does not do:

Does not decrypt traffic. It sees only encrypted mTLS bytes
Does not store anything. It is a pure relay
Does not authenticate clients beyond TLS. The mTLS authentication happens between bridge and broker through the relay

Beacon Relay Architecture

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 OpenBao. Secrets are still stored and served from the customer's EU-hosted OpenBao

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 OpenBao address, namespace targeting, rotation policies, and other settings

CLI¶

The cloudtaser-cli binary is a full lifecycle command-line tool for operators and DevOps teams.

What it does:

target check -- preflight readiness check showing container runtime, cgroup version, swap status, security module info
target install -- single-command deployment in beacon (P2P) mode (default; --mode p2p flag is optional)
target debug -- creates a DebugReport CR, collects operator diagnostics
target migrate -- migrates Kubernetes Secrets to EU OpenBao through the beacon relay, no OpenBao token needed
source register -- registers a cluster and creates an OpenBao namespace at cloudtaser/<fingerprint[:8]>
source deregister -- removes cluster registration
Discovers existing workloads, generates migration plans, validates connectivity, produces compliance audit reports, generates NetworkPolicies

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 OpenBao 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 OpenBao 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 OpenBao, 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. OpenBao is in the EU, secrets travel directly into process memory, and eBPF ensures they cannot be extracted. The cloud provider never holds the keys.

Connectivity¶

OpenBao and cluster need a network path for runtime secret delivery. cloudtaser provides three connectivity modes:

Mode	Description	Default
Beacon Relay	Both sides connect outbound to a stateless relay. Zero-config, full NAT traversal.	Yes
Reverse-Connect	Bridge connects outbound to an in-cluster broker LoadBalancer. No OpenBao inbound ports.	No
Direct	Wrapper connects directly to the OpenBao endpoint. Requires network path from pods to OpenBao.	No

Beacon relay is the default because it requires only outbound TCP 443 from both sides and works behind any firewall or NAT without configuration.

Data flow (beacon mode):

Protected pod → Operator broker → Beacon relay → Bridge → EU Vault

Both sides connect outbound -- no inbound ports, no VPNs, no firewall rules. The beacon sees only encrypted mTLS bytes.

For the token cascade running on top of this transport - how the operator mints ephemeral per-pod child vault tokens and hands them to wrappers via the HKDF-v2 unseal envelope - see Trust Chain & Per-Pod Isolation.