How CloudTaser Protects Your Data
A technical deep-dive into the architecture, kernel-level protections, and cryptographic primitives that make data sovereignty enforceable.
Secret Injection Flow
Four steps from pod creation to secrets in process memory. No Kubernetes Secrets. No disk writes. No etcd storage.
Webhook Intercepts
The mutating admission webhook watches for pods annotated with cloudtaser.io/inject: "true". When a matching pod is created, the webhook mutates the pod spec to add an init container and the wrapper sidecar.
Init Container Copies Wrapper
The init container copies the cloudtaser-wrapper binary into a shared emptyDir volume. This ensures the wrapper is available to the main container without baking it into the application image.
Wrapper Authenticates to Vault
The wrapper uses the pod's Kubernetes service account token to authenticate to your EU-hosted OpenBao or Vault instance via mTLS. It fetches the specified secrets and holds them in memory.
App Launches with Secrets
The wrapper exec's the original application entrypoint with secrets available as environment variables sourced from memory-backed file descriptors. Secrets exist only in process memory.
In-Memory Protection
Two Linux kernel mechanisms make secrets significantly harder to extract from memory, reducing the attack surface for both local and remote adversaries.
Kernel Direct Map Removal
The memfd_secret() syscall (Linux 5.14+) creates a file descriptor backed by memory pages that are removed from the kernel's direct mapping of physical memory. This makes secrets invisible to /proc/kcore scans and other processes. Note: memfd_secret does not encrypt memory contents in hardware — a physical memory dump (cold boot) could still recover data. For protection against physical access, combine with confidential computing (see below).
Swap Prevention
All secret-holding memory pages are locked with mlock() and the container runs with CAP_IPC_LOCK. This guarantees secrets are never written to swap space, even under extreme memory pressure. Combined with memfd_secret, this provides defense-in-depth at the kernel level.
Application Integration
Two approaches for delivering secrets to applications, covering both dynamically and statically linked binaries.
LD_PRELOAD Interposer
For dynamically linked applications (most languages: Python, Java, Node.js, Ruby, dynamically linked Go, C/C++), CloudTaser uses an LD_PRELOAD shared library that intercepts file-open syscalls. When your app reads from a configured secret path, the interposer serves the secret from memfd_secret-backed memory instead of the filesystem. Zero code changes required.
CloudTaser SDK
For statically linked Go binaries (common in cloud-native applications), the CloudTaser SDK provides a Go package that reads secrets directly from memfd_secret file descriptors. Import the package, call cloudtaser.GetSecret("path"), and receive the secret value from kernel-isolated memory. Minimal code change, maximum protection.
Environment Variables
As a fallback for maximum compatibility, the wrapper can expose secrets as environment variables sourced from memory-backed file descriptors. While environment variables are less isolated than memfd_secret, the eBPF enforcement layer prevents unauthorized reads via /proc/[pid]/environ.
Supply Chain Security
Every CloudTaser release is cryptographically signed and attested. Verify what you deploy.
Cosign Image Signatures
Every container image pushed to Google Artifact Registry is signed using Sigstore Cosign with keyless signing. Verify the signature before deploying to ensure the image has not been tampered with and was built by the official CI/CD pipeline.
SBOM Generation
Software Bill of Materials is generated for every release and attached as an in-toto attestation. Know exactly what dependencies are included, identify vulnerabilities, and satisfy NIS2 supply chain requirements.
Reproducible Builds
CI/CD pipelines run on GitHub Actions with pinned action versions and no third-party actions. Build artifacts are pushed to Google Artifact Registry with provenance attestation, ensuring a verifiable chain from source to deployment.
Zero-Trust Token Delivery
Every communication channel between CloudTaser components is encrypted and mutually authenticated.
Mutual TLS Token Delivery
The wrapper authenticates to the EU vault using Kubernetes service account tokens over a mutually authenticated TLS connection. Both the client (wrapper) and server (vault) present certificates and verify each other's identity. No tokens are transmitted in plaintext. Network interceptors see only encrypted traffic with no ability to extract credentials or replay requests.
Process Identity Binding
Before the application process launches, the wrapper pre-registers the expected PID with the eBPF enforcement agent. Only the registered PID can access the secret memory regions. This prevents container escape attacks from reading secrets belonging to other processes on the same node.
Confidential Computing
Hardware-based memory encryption adds defense in depth by removing trust in the hypervisor layer. This complements CloudTaser's software protections but does not replace them.
GKE Confidential Nodes
Google Kubernetes Engine supports Confidential Nodes powered by AMD SEV-SNP. Memory is encrypted with per-VM keys managed by the CPU hardware. The hypervisor cannot read guest memory in plaintext. Note: this protects against the host/hypervisor layer only — root inside the guest VM can still access process memory. CloudTaser's eBPF enforcement addresses that threat.
AKS Confidential Containers
Azure Kubernetes Service offers Confidential Containers using Intel TDX or AMD SEV-SNP. Workloads run in hardware-isolated trusted execution environments with encrypted memory. Adds protection against the hypervisor and physical host access. Does not protect against guest OS kernel compromise or privileged container escape — CloudTaser's eBPF layer handles those vectors.
EKS Nitro Enclaves
Amazon EKS with Nitro Enclaves provides isolated compute environments with no persistent storage, no interactive access, and no external networking. CloudTaser can run the wrapper inside a Nitro Enclave for strong isolation on AWS. Enclaves have limited vCPU/memory and require a vsock-based communication channel, adding architectural complexity.
What Each Layer Protects Against
CloudTaser (memfd_secret, mlock, eBPF) — protects against cloud provider access (CLOUD Act/FISA compulsion), unauthorized container/process access, and secret leakage via disk/network/core dumps. Works without confidential computing.
Confidential computing (SEV-SNP, TDX, Nitro) — protects against the hypervisor/host layer and physical memory access. Does NOT protect against guest OS kernel compromise, privileged processes inside the VM, or application-level leaks.
Together — defense in depth across the full stack. Neither alone covers all vectors. Organizations can adopt CloudTaser today and add hardware protection as provider support matures.
Known Limitations
No security solution provides absolute guarantees. CloudTaser does not protect against: a compromised guest OS kernel with direct physical memory access, application code that intentionally logs or transmits its own secrets, or hardware-level side-channel attacks on the CPU itself. Confidential computing attestation does not guarantee the absence of firmware vulnerabilities.