Security Model¶
cloudtaser is designed around a single premise: US cloud providers cannot be trusted with EU secrets. Not because they are malicious, but because US law compels them to comply with government data requests -- and EU law prohibits exactly that.
Threat Model¶
The Legal Reality¶
Two US laws create an irreconcilable conflict with EU data protection:
| Law | What It Does | Impact |
|---|---|---|
| CLOUD Act (2018) | Compels US companies to produce data stored anywhere in the world, regardless of where it is physically located | A US cloud provider must hand over data stored in EU data centers if served with a warrant |
| FISA Section 702 | Authorizes mass surveillance of non-US persons' communications through US service providers | EU citizens' data processed by US providers is subject to bulk collection without individualized warrants |
The Schrems II Problem
The Court of Justice of the European Union (CJEU) invalidated the EU-US Privacy Shield in Schrems II (C-311/18) precisely because these laws make it impossible for US companies to guarantee EU-equivalent data protection. Standard Contractual Clauses (SCCs) require supplementary technical measures -- cloudtaser provides them.
What cloudtaser Assumes¶
The adversary model covers three threat actors:
- The cloud provider itself -- has root access to hypervisors, management planes, and can be compelled by law to access customer data
- US government agencies -- can issue warrants, national security letters, and FISA orders to cloud providers
- Attackers who compromise a node -- escalate to root and attempt to extract secrets from running processes
cloudtaser's design goal: secrets never exist in any form that the cloud provider can access. They are fetched from an EU-hosted OpenBao directly into process memory on the Kubernetes node, protected by kernel-level memory isolation, and monitored by eBPF enforcement programs.
Three Defense Layers¶
cloudtaser implements defense in depth through three independent components, each addressing a different attack surface:
Layer 1: Wrapper -- Memory Isolation¶
The wrapper binary runs as PID 1 inside the container. It authenticates to your EU-hosted OpenBao or OpenBao, fetches secrets over mTLS, and stores them exclusively in protected memory regions.
| Mechanism | Protection | Kernel Requirement |
|---|---|---|
memfd_secret(2) |
Pages physically removed from kernel direct map -- invisible to root, kernel modules, /dev/mem | Linux 5.14+ |
mlock(2) |
Pages pinned in RAM, never swapped to disk | Any Linux |
MADV_DONTDUMP |
Pages excluded from core dumps | Linux 3.4+ |
PR_SET_DUMPABLE(0) |
Disables ptrace attach, restricts /proc access | Any Linux |
execve() env-var handoff |
Wrapper delivers secrets to child via standard Unix execve(); eBPF blocks cross-process /proc/PID/environ reads |
Any Linux (including statically-linked binaries) |
| cloudtaser Go SDK (optional) | Direct read from memfd_secret FD - bypasses the env-var intermediate for workloads whose threat model rejects it |
Any Linux 5.14+ |
memfd_secret is the strongest single defense
On Linux 5.14+, memfd_secret physically removes secret pages from the kernel's direct memory map. No kernel code -- not root, not kernel modules, not eBPF programs, not /dev/mem -- can read them. The only access path is through the hypervisor's physical memory view, which requires confidential computing hardware to close.
Layer 2: eBPF -- Runtime Enforcement¶
A daemonset deploys eBPF programs on every node. These programs attach to kernel functions and block or detect 35 attack vectors in real time:
- Memory access -- blocks /proc/PID/mem, /proc/PID/environ, ptrace, process_vm_readv
- Exfiltration -- blocks file writes, network sends, zero-copy I/O, DNS tunneling
- Privilege escalation -- detects kernel module and eBPF program loading
- Evasion -- blocks io_uring, userfaultfd, /dev/mem, /proc writes
Enforcement is synchronous when the kernel supports CONFIG_BPF_KPROBE_OVERRIDE (kprobe override): the syscall is blocked before it executes. On kernels without kprobe override, the agent falls back to reactive kill (SIGKILL after tracepoint detection).
Layer 3: S3 Proxy -- Storage Encryption¶
A transparent proxy sits between applications and cloud object storage (S3, GCS, Azure Blob). Data is encrypted with keys held in your EU OpenBao before it reaches the cloud provider. The provider stores only ciphertext and never holds decryption keys.
| Aspect | How It Works |
|---|---|
| Key management | Encryption keys fetched from EU OpenBao, held only in wrapper-protected memory |
| Encryption | Client-side AES-256-GCM before data leaves the pod |
| Transparency | Drop-in replacement for S3 SDK endpoint -- no application changes required |
| Key rotation | Automatic re-encryption with new keys, old ciphertext remains readable during transition |
Defense-of-the-defense: what happens if an attacker targets the eBPF daemon first?¶
A root-level attacker on the node could attempt to kill the cloudtaser-ebpf DaemonSet pod before exploiting a monitored vector. This "kill enforcement, then exploit" chain is part of the threat model. Here is what it reaches and what it does not:
memfd_secretintegrity is independent of the daemon. Secret pages are physically removed from the kernel direct map the moment the wrapper allocates them. Whether the eBPF DaemonSet is alive or dead, root on the node cannot map those pages. The single strongest defence does not depend on live enforcement.- The BPF programs live in kernel space, not the pod. Killing the userspace agent pod does not immediately unload the BPF program - the kernel holds it referenced until its file descriptors close. There is a brief post-pod-exit residual enforcement window during which the kprobes / tracepoints still fire.
- The DaemonSet runs with a restrictive SecurityContext. Ordinary workloads cannot send SIGKILL to its PID across pod boundaries - only an actor with
CAP_KILLon the host (i.e., already root-on-node) can. At that point the attacker is in scope for the next bullet anyway. - The operator watches daemon liveness and fails closed. If enforcement is unavailable on a node for longer than the configured window, the operator taints the node
NotReadyand triggers a drain. Pending admissions of new protected workloads fail closed rather than schedule onto an unprotected node. - Reschedule reloads enforcement. Kubernetes restarts the DaemonSet pod automatically; persistent suppression requires the attacker to re-kill every restart, which is observable as a CrashLoopBackOff-style signal the operator forwards to the platform audit stream.
The residual window is honest: a root-compromise-before-taint-propagation window does exist for the 35 vectors that depend on live enforcement. What we do not claim is zero-window protection for every vector. What we do claim is: memfd_secret integrity for the secret material itself - the property most deployments actually care about - holds regardless of daemon state. Operators targeting the strongest posture should pair cloudtaser with confidential-compute nodes (which compress the host-root attack surface) and node-level image verification (which prevents tampered daemon binaries from ever running).
Trust Boundaries¶
What cloudtaser Protects¶
| Threat | Protection |
|---|---|
| Cloud provider reading secrets from etcd | Secrets never enter etcd or Kubernetes Secrets API |
| Cloud provider reading secrets from disk | Secrets never written to disk (mlock, no tmpfs, no env files) |
| Cloud provider reading process memory | memfd_secret removes pages from kernel direct map (5.14+) |
| Root attacker dumping /proc | PR_SET_DUMPABLE + eBPF blocks /proc/PID/mem and /proc/PID/environ |
| Root attacker using ptrace | eBPF blocks ptrace ATTACH/SEIZE on monitored processes |
| Container escape followed by host-level exfiltration | eBPF enforcement runs on the host, monitors all attack vectors |
| Network exfiltration of secrets | eBPF content matching on sendto/sendmsg, plus NetworkPolicy |
| Core dump exposure | MADV_DONTDUMP + eBPF blocks coredump_filter writes |
What cloudtaser Does NOT Protect¶
Understand the boundaries
No security product protects against everything. These are the known limitations.
| Threat | Why | Mitigation Path |
|---|---|---|
| Hypervisor-level memory inspection | The hypervisor has physical access to VM RAM | Confidential computing (AMD SEV-SNP, Intel TDX, ARM CCA) |
| DMA attacks from host devices | Physical memory access bypasses all software protections | Confidential computing with IOMMU enforcement |
| Cold boot attacks | Physical RAM can be frozen and read | Confidential computing with memory encryption |
| Application logic bugs that log or transmit secrets | cloudtaser protects memory, not application behavior | eBPF content matching catches known patterns; code review for the rest |
| Secrets during active CPU processing | Values in CPU registers during computation | Spectre/Meltdown kernel mitigations (verified by protection score) |
| Hibernate / suspend-to-disk | Full RAM written to disk as a kernel-level operation | Disable hibernate on cloudtaser nodes |
Comparison with Alternatives¶
cloudtaser's approach is fundamentally different from other Kubernetes secret management tools because it eliminates the Kubernetes Secrets API as an attack surface entirely.
| cloudtaser | Vault Agent | External Secrets Operator | Sealed Secrets | |
|---|---|---|---|---|
| Secrets in etcd | Never | Never (with annotations) | Yes -- creates K8s Secrets | Yes -- creates K8s Secrets |
| Secrets on disk | Never | Yes -- writes to tmpfs/volume | Yes -- mounted as files or env vars | Yes -- standard K8s Secret mount |
| Memory protection | memfd_secret, mlock, MADV_DONTDUMP | None | None | None |
| Runtime enforcement | 35 eBPF vectors | None | None | None |
| Root attacker resistance | memfd_secret (5.14+) hides from root | Root can read tmpfs files | Root can read mounted secrets | Root can read mounted secrets |
| Cloud provider resistance | Full stack -- memory, eBPF, storage | OpenBao is EU-hosted but secrets land in plaintext on node | Provider can read etcd | Provider can read etcd |
| Application changes | None (wrapper sets env vars via execve() - static Go included) · Optional SDK for memfd-only posture |
None (file/env template) | None (K8s native) | None (K8s native) |
The key difference
Vault Agent, ESO, and Sealed Secrets all eventually produce a Kubernetes Secret or a file on disk. cloudtaser never does. Secrets exist only in process memory, protected by kernel-level isolation and monitored by eBPF enforcement.
vs. confidential-compute-native and sovereign-cloud stacks¶
cloudtaser is not the same class of product as a CC-native Kubernetes distribution or a sovereign-cloud provider. A serious evaluation should understand the trade-off explicitly.
| cloudtaser | Nitro Enclaves (direct) | Constellation (Edgeless) | Fortanix / SCONE | SecNumCloud (OVH / Bleu / Outscale) | |
|---|---|---|---|---|---|
| Deployment shape | Annotation-based operator on existing GKE / EKS / AKS | App-level enclave on EC2 | Replaces the K8s distribution with a CC-native one | Application-level TEE runtime (SGX / SEV) | Replaces the cloud provider |
| Code changes required | None (wrapper env-var handoff) · SDK optional | Yes - app must be enclave-aware (Nitro vsock API) | None in most cases - existing manifests still work | Yes - apps ported to run inside enclave | None - app runs as usual |
| Hypervisor-memory sovereignty | Only on CC node SKUs (see deployment guide) | Yes - hardware enclave | Yes - all nodes are SEV-SNP/TDX | Yes - TEE isolation | Depends - N/A if provider already trusted |
| Multi-cloud portability | Yes - GKE / EKS / AKS / self-managed | No - AWS-only | Yes, but requires the Constellation distro | Varies - SGX is Intel-only, SEV is AMD-only | No - you commit to one sovereign provider |
| Migration cost | Helm install + annotations | Rewrite application for Nitro | Migrate the cluster onto Constellation | Port applications into enclaves | Move workloads off hyperscaler |
| Schrems II supplementary-measure story | Yes, conditional on substrate (CC + EU-hosted OpenBao) | Yes on AWS-EU | Yes - full stack CC | Yes at the application layer | Native - provider is EU-sovereign |
| Ecosystem lock-in | Low - still on standard K8s | High - AWS APIs | Medium - Constellation distro | Medium - TEE runtime dependency | High - leaving the sovereign provider is hard |
| Maturity | Preview (2026) | GA, production | GA, production | GA, established | GA, regulated |
| Where cloudtaser wins | You already committed to managed K8s and can't re-platform | - | - | - | - |
Positioning in plain language. cloudtaser is the incrementalist path: you have GKE / EKS / AKS for talent, ecosystem, and tooling reasons, you cannot migrate to a CC-native distro or leave the hyperscaler, and you need a Schrems II supplementary-measure story that survives audit. The alternatives above are strictly stronger in specific dimensions - Nitro Enclaves is hardware-isolated but AWS-only and code-invasive; Constellation gives you CC at the cluster level but requires a migration; SecNumCloud providers give you sovereign-by-construction at the cost of leaving the hyperscaler ecosystem. None of these is the same product. If you can re-platform and the alternatives fit, take them - cloudtaser exists for customers who cannot.
We document this because it's the most honest answer to "why cloudtaser and not X?" and it's the question every procurement committee asks. If the answer is "we can move to OVH / Bleu" and the business tolerates it, OVH / Bleu is often the cleaner outcome.
Protection Levels¶
Level 1: Software Complete (Current)¶
With CLOUDTASER_REQUIRE_MEMFD_SECRET=true on Linux 5.14+, cloudtaser provides software-complete protection. The only remaining exposure is the hypervisor's physical memory view.
Level 2: Hardware Complete (Future)¶
With confidential computing hardware (AMD SEV-SNP, Intel TDX, ARM CCA), the hypervisor gap closes. cloudtaser + confidential computing = complete secret isolation at every layer:
- Software: cloudtaser enforcement (35 eBPF vectors)
- Kernel: memfd_secret (hardware-backed memory hiding)
- Hardware: Confidential computing (encrypted VM memory)
Protection Score | Root Attack Surface | Trust Chain & Per-Pod Isolation