TL;DR — What Is Phantom?
Three components. One goal: your secrets never touch the cloud provider.
Phantom = eBPF DaemonSet + Process Wrapper + External SaaS
The Problem
You run Kubernetes on AWS, GCP, or Azure. Your secrets (API keys, DB credentials, TLS certs) are stored in Kubernetes Secrets, which live in etcd — a database the cloud provider fully controls. A CLOUD Act subpoena or FISA 702 order compels the provider to hand everything over. Your encryption keys? They hold those too.
Your data is one legal request away from disclosure.
The Solution
Phantom ensures secrets never enter Kubernetes. Instead, they’re fetched at runtime from an EU-hosted vault directly into process memory. The cloud provider never sees them, never stores them, and has nothing to hand over.
No code changes. No migration. Just install a Helm chart.
Three Components
eBPF DaemonSet
A DaemonSet that deploys eBPF programs to monitor syscalls and network activity at the kernel level. It watches every process on every node and answers: is anything accessing secrets it shouldn’t? Is data leaving the cluster unencrypted?
- What it monitors:
sys_read,sys_write,sys_openat, networkconnect/sendmsgcalls - What it detects: Unencrypted secret access via
/proc/[pid]/mem, unexpected outbound connections, processes reading files they shouldn’t - What it does: Alerts, generates audit events, feeds the SaaS dashboard with real-time observability
- Analogy: Like Falco, but purpose-built for secret access patterns and data sovereignty compliance
Phase 2 / Optional
The eBPF layer is defense-in-depth. Phantom’s core protection (secrets never in etcd) works without it. eBPF adds runtime visibility and alerting for enterprises that need continuous compliance evidence.
Process Wrapper (Mutating Webhook + Sidecar)
A mutating admission webhook automatically injects a sidecar container (phantom-proxy) into every labeled pod. The sidecar works like envconsul — it fetches secrets from the external vault and injects them directly into the application’s process as environment variables, files, or via a Unix socket.
- How it works: Pod created → webhook intercepts → injects sidecar → sidecar authenticates to OpenBao → fetches secrets → passes to app process → app starts with secrets in memory
- Secret delivery: Environment variables (like envconsul), tmpfs-mounted files, or Unix domain socket API
- Caching: Three-tier cache (hot in-memory → sealed local → grace period) so pods survive vault outages
- Circuit breaker: If the webhook fails, existing pods keep running. New pods get a clear error, not silent failure
- Analogy: Like
envconsulorvault-agent, but injected transparently via Kubernetes webhook — zero code changes required
This is the core product
The webhook + sidecar is what ships in v1. It’s the piece that makes secrets bypass etcd entirely. Everything else builds on top of this.
External SaaS (EU-Hosted OpenBao)
A managed OpenBao (open-source Vault fork) instance hosted in the EU, outside US legal jurisdiction. This is where all secrets live. The cloud provider never has access to it. Keys are backed by HSMs. When a CLOUD Act subpoena arrives, the provider can only hand over ciphertext — the keys are in a different legal jurisdiction.
- What it stores: All customer secrets, encryption keys, TLS certificates, database credentials
- Where it runs: EU data center (customer-managed or CloudCondom-managed SaaS)
- Authentication: Kubernetes service account tokens + optional hardware attestation (SEV-SNP/TDX)
- Key management: HSM-backed unseal keys, automatic rotation, audit logging
- SaaS dashboard: Secret access logs, compliance reporting, risk alerts, sovereignty status per cluster
- Analogy: Like HashiCorp Cloud Vault, but open-source, EU-hosted, and purpose-built for sovereignty compliance
Revenue driver
The managed OpenBao SaaS is the primary revenue stream. Open-source the webhook + sidecar, charge for managed secrets infrastructure. Eliminates the #1 operational risk (Vault expertise) and the rarest skill requirement for customers.
How They Work Together
What Happens When...
| Event | Without Phantom | With Phantom |
|---|---|---|
| CLOUD Act subpoena arrives | Provider hands over etcd dump with all secrets in plaintext | Provider hands over etcd — no secrets there. Keys are in EU OpenBao, outside US jurisdiction |
| Cluster-admin compromised | Attacker reads all K8s Secrets with kubectl get secrets |
Nothing to read — secrets aren’t in Kubernetes. Attacker can delete webhook (future pods unprotected) but can’t extract secrets from running pods |
| GDPR audit / TIA requested | Scramble to explain why secrets are in US-controlled etcd | Show cryptographic proof: secrets never leave EU jurisdiction, customer holds all keys |
| New pod starts | Reads secrets from etcd via K8s API | Webhook injects sidecar → sidecar fetches from EU OpenBao → secrets in memory only |
| OpenBao goes down | N/A | Running pods use cached secrets (grace period). New pods wait. No data loss |
“But we have HYOK / Cloud EKM”
Every cloud offers Hold Your Own Key / External Key Manager. You control the key, they encrypt with it. Sounds like it solves the problem. It doesn’t:
- Keys enter provider RAM during use — HYOK protects at rest, not in use. A CLOUD Act order compels interception during decryption
- Provider controls compute — hypervisor, etcd, kubelet. They can snapshot memory. Your external key is used inside their infra
- K8s Secrets still plaintext on read — EKM encrypts etcd storage, but
kubectl get secretreturns plaintext regardless - Revocation kills everything — revoking your key stops all workloads. Nuclear option, not a security control
Phantom is different
Secrets never enter the provider’s infrastructure at all. Not at rest, not in transit, not in memory. They go from EU OpenBao → sidecar → process memory. The provider has nothing to decrypt, intercept, or hand over.
Runtime Memory Protection
Secrets in process memory are protected by three layers that require no special hardware — just a Helm install:
- eBPF detection — monitors
ptrace,/proc/[pid]/mem,process_vm_readvand alerts on any attempt to read protected process memory - Short-lived credentials — sidecar rotates derived tokens (15-min TTL). A memory dump yields secrets that expire quickly
- Memory hygiene —
PR_SET_DUMPABLE=0,mlock(), secrets zeroed after injection
Hypervisor-level reads (provider accessing VM memory directly) require TEE (confidential VMs) to block. TEE is supported as an optional upgrade, not a requirement.
If You Know These, You Know Phantom
envconsul / vault-agent
Fetches secrets from Vault, injects as env vars into a process
Kubernetes Mutating Webhook
Automatically modifies pods at creation time — no manual config per app
Falco / Tetragon (eBPF)
Kernel-level runtime observability for security events
EU-hosted Managed Vault
HSM-backed secrets management outside US legal reach
Phantom is envconsul that installs itself via webhook, stores secrets in EU-hosted OpenBao, monitors access via eBPF, and gives you a SaaS dashboard to prove compliance.