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 vault 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 Vault, 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 |
| Environment scrubbing | Clears /proc/PID/environ after secrets are loaded | Any Linux |
| LD_PRELOAD interposer | Intercepts getenv() to return memfd pointers instead of heap copies |
Any Linux (dynamically linked apps) |
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.
:octicons-arrow-right-24: Memory Protection Details
Layer 2: eBPF -- Runtime Enforcement¶
A daemonset deploys eBPF programs on every node. These programs attach to kernel functions and block or detect 19+ 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).
:octicons-arrow-right-24: eBPF Enforcement Vectors
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 vault 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 vault, 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 |
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 |
Statically linked Go binaries calling os.Getenv() |
LD_PRELOAD cannot intercept statically linked functions | Use CloudTaser SDK for direct memfd access |
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 | 19+ 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 | Vault is EU-hosted but secrets land in plaintext on node | Provider can read etcd | Provider can read etcd |
| Application changes | None (LD_PRELOAD) or minimal (SDK) | 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.
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 (19+ eBPF vectors)
- Kernel: memfd_secret (hardware-backed memory hiding)
- Hardware: Confidential computing (encrypted VM memory)
:octicons-arrow-right-24: Protection Score | :octicons-arrow-right-24: Root Attack Surface