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. Wraps the application process at startup — no sidecar containers. Fetches secrets from EU/UK vault into process memory via init container + entrypoint rewrite. LD_PRELOAD interposer delivers secrets transparently to dynamically linked applications; Go SDK for statically linked binaries.
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.
Enforcement Layer
20+ eBPF enforcement vectors in the kernel block secret access — /proc hardening, ptrace, perf_event_open, io_uring, userfaultfd, write monitoring, global privilege escalation detection, and CPU vulnerability verification (Spectre/Meltdown).
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 delivers them via memfd file descriptors. For dynamically linked applications (PostgreSQL, MySQL, Redis, Node.js, Python, Java), the LD_PRELOAD interposer intercepts getenv() calls transparently — no application changes needed. For statically linked Go binaries, the CloudTaser SDK reads secrets directly from the memfd. Then the wrapper 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.
In-Memory Secret Protection
Why CloudTaser is the only Kubernetes tool that makes secrets invisible to the kernel.
Every secret management tool — Vault Agent, External Secrets Operator, SOPS, AWS Secrets Manager — stores secrets in regular process memory after delivery. Regular memory is readable by anyone with root access: via /proc/pid/mem, ptrace, core dumps, or even the hypervisor's view of physical memory.
CloudTaser uses two Linux kernel primitives that no other Kubernetes secret tool uses:
memfd_secret(2)
Linux 5.14+ syscall that creates memory pages removed from the kernel's direct map. The physical memory backing these pages is unmapped from the kernel's linear address space. This means:
- Not visible in
/proc/pid/mem— reads return zeroes - Not accessible via
ptrace— debuggers see nothing - Not in the kernel direct map — the kernel itself cannot read the pages
- Not visible to the hypervisor — the cloud provider's infrastructure cannot access the physical memory
mlock(2) + dump exclusion
Complementary protections that close remaining attack vectors:
mlock— pins secret pages in physical RAM, preventing swap-out to disk under any circumstancesMADV_DONTDUMP— excludes secret regions from core dumps, so crashes never leak credentialsPR_SET_DUMPABLE(0)— prevents the process from being dumped entirely- Combined with 20+ eBPF enforcement vectors that block every known runtime access path
CLOUDTASER_REQUIRE_MEMFD_SECRET — Strict Mode
When strict mode is enabled, the wrapper refuses to start if the kernel does not support memfd_secret(2). This guarantees hardware-level memory hiding is active — secrets are physically removed from the kernel's direct memory map. On pre-5.14 kernels or kernels without CONFIG_SECRETMEM=y, the pod fails fast rather than running with weaker protection.
memfd_secret requires Linux 5.14+ with CONFIG_SECRETMEM=y, mlock requires CAP_IPC_LOCK and adequate RLIMIT_MEMLOCK — both need container security context adjustments. Other tools optimize for "just deploy it" simplicity. CloudTaser's wrapper architecture handles the kernel configuration automatically, so your application doesn't need to change.
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 Enforcement
20+ eBPF enforcement vectors blocking every known path to secret extraction — at the kernel level.
The eBPF agent runs as a DaemonSet and attaches kprobes and tracepoints to enforce secret access at the kernel level. It covers process debugging, filesystem access, async I/O, hardware watchpoints, and privilege escalation — returning -EACCES synchronously before any data leaves the process.
/proc Hardening
Blocks 12+ /proc filesystem paths on protected processes — environ, mem, maps, smaps, syscall, stack, coredump_filter, status, wchan, pagemap, cmdline, and more. Returns -EACCES even as root.
ptrace Blocking
Blocks ptrace attach and seize on protected processes. Prevents debugger-based secret extraction — gdb, strace, and any tool that uses PTRACE_ATTACH.
Write Monitoring
Detects and blocks when secret material appears in write() or sendto() buffers — prevents exfiltration via logs, network, or files.
perf_event_open Blocking
Prevents hardware watchpoint attacks on protected memory. Hardware breakpoints can monitor memory reads/writes without ptrace — this vector blocks perf_event_open for protected PIDs.
io_uring Blocking
Prevents async I/O bypass of syscall monitoring. io_uring submits syscalls via shared ring buffers, bypassing normal syscall entry points — CloudTaser blocks io_uring_setup for protected processes.
userfaultfd Blocking
Prevents page-fault side-channel attacks. userfaultfd can be weaponized to observe memory access patterns — CloudTaser blocks it on protected processes.
Memory Protection
Secrets stored via memfd_secret (hidden from kernel direct map), locked in RAM with mlock (never swapped), excluded from core dumps via MADV_DONTDUMP and PR_SET_DUMPABLE(0).
Global Privilege Escalation Detection
Detects kernel module loading (init_module, finit_module) and eBPF program loading from ANY process system-wide — not just protected processes. Catches attackers trying to load rootkits or malicious eBPF programs to bypass enforcement.
memfd_secret (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, CloudTaser provides the most comprehensive runtime secret protection available.
Every access attempt is logged with PID, command, timestamp, and severity. Events forward to your SIEM for GDPR/NIS2/DORA compliance.
Application Integration
Transparent secret delivery for any application — no code changes required.
LD_PRELOAD Interposer
For dynamically linked applications — PostgreSQL, MySQL, Redis, Node.js, Python, Java, and any other application using glibc or musl. The wrapper injects a shared library via LD_PRELOAD that intercepts getenv() calls at the C library level. Secrets are delivered through memfd file descriptors and served transparently when the application reads environment variables.
- No application changes — works with unmodified binaries
- Secrets never appear in
/proc/pid/environ - memfd file descriptors are invisible to other processes
- Supports any dynamically linked application out of the box
CloudTaser SDK
For statically linked Go applications that cannot use LD_PRELOAD. The SDK provides direct access to secrets via the memfd file descriptor without any environment variable exposure. Import the package, read secrets from the memfd — no vault client needed in your application.
- Designed for statically linked Go binaries
- Direct memfd access — no env var intermediary
- Lightweight — no Vault SDK dependency in your app
- Works with the same wrapper + eBPF protection stack
/proc/pid/environ. The LD_PRELOAD interposer and SDK both deliver secrets through memfd file descriptors that are invisible to other processes and protected by the full eBPF enforcement stack.
CPU Vulnerability Verification
Verifies hardware-level protections are active before trusting memory isolation.
Memory isolation is only as strong as the CPU it runs on. Spectre and Meltdown class vulnerabilities can bypass software memory protections by exploiting speculative execution. CloudTaser checks that mitigations are active on the host CPU and factors this into the protection score.
Verifies bounds check bypass and branch target injection mitigations are active. Checks kernel-reported vulnerability status.
Confirms KPTI (Kernel Page Table Isolation) is enabled. Essential for memfd_secret to provide real isolation from kernel-space attacks.
CPU vulnerability status feeds into CloudTaser's protection score. Unmitigated vulnerabilities lower the score and trigger alerts via Prometheus metrics.
Observability
Real-time metrics for monitoring, alerting, and compliance.
CloudTaser exposes 7 Prometheus metrics at /metrics for real-time monitoring and alerting. Integrate with Grafana, Datadog, or any Prometheus-compatible stack.
| Metric | Description |
|---|---|
cloudtaser_protection_score |
Current protection score (0-100) per pod |
cloudtaser_secret_fetches_total |
Total secret fetch operations |
cloudtaser_lease_renewals_total |
Total vault lease renewals |
cloudtaser_ebpf_blocks_total |
Total eBPF enforcement actions |
cloudtaser_memfd_secret_available |
Whether memfd_secret is supported (0/1) |
cloudtaser_cpu_vulnerabilities |
CPU vulnerability mitigation status |
cloudtaser_injection_errors_total |
Total injection failures |
cloudtaser_protection_score to detect when kernel features are unavailable, CPU mitigations are missing, or enforcement vectors are reduced. Catch configuration drift before it becomes a security gap.
Supply Chain Security
Hardened CI/CD pipeline, signed images, and automated vulnerability scanning.
Cosign Image Signing + SBOM
Every CloudTaser container image is signed with Sigstore cosign using keyless signing. A Software Bill of Materials (SBOM) is generated with syft and attached to each image. Verify image provenance before deployment — if the signature doesn't match, the image hasn't been tampered with.
Trivy Vulnerability Scanning
CI pipeline scans every container image for HIGH and CRITICAL vulnerabilities using Trivy. Builds fail if vulnerabilities are found — no image ships with known critical security issues. Scan results are available in CI logs for audit.
Image Registry Verification
The mutating admission webhook verifies that container images come from trusted registries before injection. If an image is pulled from an untrusted registry, injection is denied. Prevents supply chain attacks where malicious images are substituted.
Container Security Hardening
Injected containers automatically receive hardened security settings: seccomp RuntimeDefault profile, readOnlyRootFilesystem, and resource limits (CPU/memory). The operator applies these to every injected sidecar — no manual SecurityContext configuration needed.
Inter-Component Security
Defense-in-depth between the operator, wrapper, and eBPF agent.
Unix Domain Socket
Agent communication uses Unix domain sockets instead of TCP. Eliminates network attack surface entirely — no ports, no network listeners, no remote exploitation vectors. Communication stays within the node.
Mandatory mTLS on Unseal
The unseal endpoint requires mutual TLS — only the operator can deliver vault tokens to the wrapper. No other process on the node can impersonate the operator or intercept token delivery.
PID Pre-Registration
The wrapper pre-registers process PIDs with the eBPF agent before exec — zero gap between process start and enforcement. Fork auto-tracking ensures child processes inherit protection immediately.
Least-Privilege DaemonSet
The eBPF agent runs with explicit capabilities — no privileged: true. Only the minimum kernel capabilities needed for eBPF program loading and tracepoint attachment are granted.
mlock Enforcement
Fail-fast option prevents secrets from being swappable to disk. If CAP_IPC_LOCK is unavailable, the wrapper can refuse to start rather than storing secrets in swappable memory.
Token Memory Protection
Vault tokens are protected with mlock across all components — operator, wrapper, and eBPF agent. Tokens never touch swap, even under memory pressure.
Hardware-Level Protection
Pick the right node pool machine type and get full-stack encryption — from hardware to legal jurisdiction.
All major cloud providers offer confidential computing VMs that encrypt memory at the hardware level using AMD SEV-SNP. Even a compromised hypervisor cannot read your VM memory. Combined with CloudTaser, you get protection at every layer.
Google Cloud (GKE)
Confidential GKE Nodes
Enable with --enable-confidential-nodes on your node pool. Uses n2d-standard-* machine types (AMD EPYC with SEV-SNP). First-class GKE integration — no custom configuration needed.
Azure (AKS)
Confidential VM Node Pools
Use DCasv5 / DCadsv5 (general purpose) or ECasv5 / ECadsv5 (memory optimized) VM sizes. AMD SEV-SNP on 3rd Gen EPYC. First-class AKS integration — the most mature confidential K8s offering.
AWS (EKS)
AMD SEV-SNP Instances
Use M6a (general purpose), C6a (compute optimized), or R6a (memory optimized) instance families. Configure via launch templates on your EKS node groups. AMD SEV-SNP encrypts VM memory at the hardware level.
What confidential nodes protect — and what they don't:
RAM encrypted with per-VM keys managed by the AMD Secure Processor. The cloud provider's hypervisor cannot read your VM memory. Works with standard K8s workloads — no app changes needed.
Secrets within the VM are still visible across processes (/proc/pid/environ). Secrets in etcd and K8s Secrets are still exposed at the orchestration layer. The provider can still be compelled under CLOUD Act.
The "Only Hypervisor" Security Boundary
With CloudTaser's full stack deployed — memfd_secret hiding secrets from the kernel, LD_PRELOAD interposer preventing env var exposure, 20+ eBPF enforcement vectors blocking all known runtime access paths, and CPU vulnerability verification confirming Spectre/Meltdown mitigations — the only remaining attack vector is hypervisor-level physical memory access.
This is where confidential computing closes the final gap. AMD SEV-SNP, Intel TDX, and ARM CCA encrypt VM memory at the hardware level, making it inaccessible even to a compromised hypervisor. With CloudTaser + confidential nodes, no software layer — from kernel to cloud provider — can access your secrets.
memfd_secret physically removes secrets from the kernel's direct memory map, LD_PRELOAD interposer and SDK deliver secrets via memfd without env var exposure, 20+ eBPF vectors block /proc, ptrace, perf_event_open, io_uring, and userfaultfd attacks, CPU vulnerability verification ensures Spectre/Meltdown mitigations are active, the wrapper keeps secrets out of etcd with mTLS token delivery and mlock enforcement, and EU-hosted vault keeps keys under EU jurisdiction. Together they cover hardware → OS → runtime → Kubernetes → legal.
Deployment
Single Helm chart, works with any managed Kubernetes (GKE, EKS, AKS).
# Install CloudTaser (preview)
helm pull oci://ghcr.io/skipopsltd/cloudtaser-helm/cloudtaser --version 0.1.20
helm upgrade --install cloudtaser cloudtaser-0.1.20.tgz \
--namespace cloudtaser-system --create-namespace \
--set operator.vaultAddress="https://vault.eu.example.com"
# 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.