How CloudTaser Works
A technical deep-dive into the architecture, encryption model, and deployment flow.
Architecture
Three layers protecting secrets at rest, in transit, and in memory.
Injection Layer
Kubernetes admission webhook intercepts pod creation. Injects a sidecar that fetches secrets from EU vault into process memory. The original container starts only after secrets are available.
Encryption Layer
S3-compatible proxy performs client-side envelope encryption. Each object gets a unique AES-256-GCM data key, wrapped through Vault Transit. Cloud storage holds only ciphertext.
Monitoring Layer
eBPF tracepoints in the kernel detect unauthorized secret access — environment variable reads, unexpected network sends containing secret material.
Secret Injection Flow
How secrets get from EU vault into your application without touching Kubernetes.
Pod created with CloudTaser annotations
You add annotations to your deployment spec: cloudtaser.io/inject: "true" and cloudtaser.io/secrets pointing to vault paths. No other changes needed.
Webhook intercepts and mutates
The mutating admission webhook detects the annotations. It adds an init container with the wrapper binary, rewrites the container command to launch through the wrapper, and resolves the original entrypoint from the container registry.
Wrapper fetches secrets at startup
The wrapper authenticates to the EU vault (Kubernetes auth or token), fetches the specified secrets, and sets them as environment variables. Then it fork+execs the original process. Secrets exist only in memory.
Leases renewed automatically
The wrapper monitors vault lease expiry and renews before TTL. If a lease can't be renewed, it re-fetches the secret. Token renewal runs in the background.
kubectl get secrets returns nothing CloudTaser-related. Secrets never appear in etcd, pod specs, or on disk. An attacker with access to the Kubernetes API sees no credentials.
Object Storage Encryption
Client-side envelope encryption for any S3-compatible storage.
Application sends PUT request
Your application targets the CloudTaser S3 proxy (drop-in replacement for the provider endpoint). Standard S3 SDKs work unchanged.
Proxy generates a unique data key
For each object, the proxy requests a new data encryption key (DEK) from Vault Transit. Vault returns both the plaintext DEK and a wrapped (encrypted) copy.
Object encrypted, key discarded
The proxy encrypts the object body with AES-256-GCM using the plaintext DEK. The wrapped DEK is stored as S3 object metadata. The plaintext DEK is discarded — it exists only for the duration of the request.
Decryption is transparent
On GET, the proxy reads the wrapped DEK from metadata, asks Vault to unwrap it, decrypts the object, and returns plaintext to the application. The cloud provider never has access to plaintext or keys.
Runtime Monitoring
Kernel-level visibility into secret access patterns.
The eBPF agent runs as a DaemonSet and attaches tracepoints to system calls. It monitors:
Detects when secret material appears in write() or sendto() buffers — potential exfiltration via logs, network, or files.
Detects processes reading /proc/pid/environ of monitored containers — a common side channel for extracting injected secrets.
Events are emitted with severity levels and can be forwarded to your SIEM or observability stack. Enforcement (blocking unauthorized access at the kernel level) is in active development.
Deployment
Single Helm chart, no CRDs, works with any managed Kubernetes.
# Install CloudTaser
helm repo add cloudtaser https://charts.cloudtaser.io
helm install cloudtaser cloudtaser/cloudtaser \
--set vault.addr=https://vault.eu.example.com \
--set vault.authMethod=kubernetes
# Annotate your deployment
kubectl annotate deployment myapp \
cloudtaser.io/inject="true" \
cloudtaser.io/secrets="secret/data/myapp/db"
# Restart pods to pick up injection
kubectl rollout restart deployment myappTry it yourself
Interactive terminal demos — see secrets injected into memory and objects encrypted client-side.