cloudtaser, KubeArmor, Tetragon - they compose.
Procurement teams ask: "do I have to choose between cloudtaser and Tetragon or KubeArmor?" The honest answer is no. cloudtaser is a secret-material lifecycle stack with EU sovereignty as the differentiator. KubeArmor and Tetragon are general-purpose runtime-security policy frameworks. Different shapes, different jobs, different teams owning them. They run side by side in the clusters we work in. With the BPF LSM migration (cloudtaser-ebpf #179 Phases L1-L4) merged and rolling out, all three target the same BPF LSM kernel-hook layer by design and are intended to compose without an LSM-stack conflict.
Three projects, three different jobs.
It is tempting to flatten "runtime security on Kubernetes" into one slot on a procurement matrix. The shape of the problems each project solves is different enough that flattening produces the wrong answer.
cloudtaser
A secret-material lifecycle stack. The job is: keep the keys, secrets, and confidential payloads in your jurisdiction (EU-hosted OpenBao on a sovereign substrate), deliver them into pod memory through a wrapper without ever materialising them on disk or in etcd, and prove cryptographically that the cloud provider cannot decrypt on compulsion. The product surface is mutating webhook + wrapper + eBPF agent + beacon relay + bridge, with a single-command CLI deploying the lot. The differentiator is EU data sovereignty; the proof is memfd_secret + the wrapper's dumpable=0 + BPF LSM hooks on the five highest-risk kernel entry points (kprobe fallback on kernels without CONFIG_BPF_LSM=y). We are not a general policy engine and we are not a marquee detection tool.
KubeArmor
A workload-policy enforcement framework, originally Accuknox, now CNCF Sandbox. The job is: declarative allow/deny policies for files, processes, network endpoints, and capabilities at the per-pod level, enforced at the kernel boundary through LSM hooks (AppArmor / SELinux / BPF LSM depending on the host kernel). Strong, mature project; broad supported policy surface; the right tool when "what can this pod read/exec/network-to" is the question you are answering.
Tetragon
A runtime detection and policy framework from the Cilium family, also CNCF. The job is: deep visibility into kernel-level events (process execution, file access, network flows, capability use, namespace transitions) with high-throughput eBPF instrumentation, plus the ability to enforce on a subset of those events. Marquee strength is the audit and detection telemetry surface - "what just happened on this node, and what does the trail look like over time".
cloudtaser does not try to compete with KubeArmor on policy expressiveness or with Tetragon on detection breadth. We do one thing - the secret-material lifecycle with sovereignty - and we do it deeper than a general framework can without specialising.
Capability-by-capability, honestly.
This table names the capability a procurement matrix tends to ask about, then says which project owns it as a core feature. "Core" means designed-for-and-shipped; blank means out of scope by intent; "general" means the project handles it via its general policy / detection surface but does not specialise.
| Capability | cloudtaser | KubeArmor | Tetragon |
|---|---|---|---|
| Secret-material lifecycle (memfd_secret, EU vault, beacon, attestation) | Core | Out of scope | Out of scope |
| Workload policy enforcement (allow/deny file / process / network / capability) | Out of scope | Core | Core |
| EU data sovereignty narrative | Core | Out of scope | Out of scope |
| Compliance posture (DORA, NIS2, GDPR, Schrems II Art. 46) | Specialised | General | General |
| Detection + audit telemetry | Per-event Prometheus + audit hook | Strong | Marquee |
| Kernel-hook stack (eBPF kprobe / tracepoint / LSM) | BPF LSM (kernel 5.7+, kprobe fallback on older kernels) | BPF LSM (kernel 5.7+) or AppArmor / SELinux | eBPF tracepoints + kprobes |
| App code changes | None (annotations + wrapper) | None (CRDs) | None (CRDs / TracingPolicy) |
| License | Source-available, commercial | Apache 2.0 (CNCF Sandbox) | Apache 2.0 (CNCF Incubating) |
No row above is a knock on the others. KubeArmor and Tetragon are mature open-source CNCF projects with bigger contributor communities than ours; cloudtaser is a specialised commercial overlay. Different shapes.
If you already run KubeArmor or Tetragon, cloudtaser layers on top.
The composition is straightforward because the products operate at different layers of the same threat model.
If you already run KubeArmor
Keep your existing KubeArmor policies for workload hardening - the file/process/network/capability allow-deny rules that your SecOps team has tuned. cloudtaser layers on top for the secrets path: the wrapper sets PR_SET_DUMPABLE=0 on protected processes, and the eBPF agent (now using BPF LSM hooks for synchronous denial on the five highest-risk entry points) provides memory-read syscall coverage. Secret retrieval routes through your EU-hosted OpenBao via the beacon relay. KubeArmor's policy boundary and cloudtaser's secret boundary do not overlap; both now operate at the BPF LSM layer and compose cleanly.
If you already run Tetragon
Same shape. Keep Tetragon for cluster-wide detection telemetry and TracingPolicy enforcement; cloudtaser handles the secret-material lifecycle with dumpable=0 + BPF LSM enforcement on the secret-handling pods. Tetragon's policies and cloudtaser's secret-flow are independent.
If you already run cloudtaser
You already have the secrets path closed. Adding KubeArmor or Tetragon brings workload-policy enforcement and detection breadth that we do not specialise in. We will not try to talk you out of either.
What the composition prevents you from doing
One concrete edge: avoid configuring KubeArmor or Tetragon to deny the syscalls cloudtaser depends on for secret delivery (memfd_secret, execve in the wrapper, the beacon-relay outbound). The default policy posture in either project does not block these, but a hardened bespoke policy could. Documentation in the cloudtaser deployment guide names the syscall set so SecOps can carve the right exception.
Kernel-stack compatibility, now on BPF LSM.
cloudtaser's eBPF agent attaches BPF LSM hooks as the primary enforcement path in the upcoming release (Phase L4, code merged May 2026). The five highest-risk kernel entry points — ptrace_access_check, file_open, bpf, socket_sendmsg, and kernel_load_data — are designed to be denied synchronously by the LSM hook before the kernel action completes. This is the same hook layer KubeArmor uses for its modern path. The three projects target the same kernel-hook stack and are intended to compose without an LSM-stack conflict; per-kernel runtime confirmation across the full matrix lands once cloudtaser-pipeline#227 unblocks the verifier-test workflow.
On kernels where CONFIG_BPF_LSM=y is not set, or where bpf is absent from /sys/kernel/security/lsm (some hardened distros, GKE pre-1.27, AKS Mariner), the agent detects this at startup and falls back automatically to kprobe + tracepoint enforcement. No configuration change required. kprobe coverage on the full attack surface remains active in both modes.
When to choose what.
The honest answer is rarely a single-project choice. Most regulated EU workloads land on at least two of the three.
Pick cloudtaser when
- The procurement question is "what happens when AWS / GCP / Azure receives a CLOUD Act subpoena?" - and the answer needs to be "they only have ciphertext".
- You need a Schrems II Art. 46 supplementary measure that a DPO will sign without conditions.
- Your secrets currently live in K8s Secrets / etcd / a US-jurisdiction managed secret store, and you want them out of all three.
Pick KubeArmor when
- Workload hardening is the question - "this pod must only read /etc/config and write /var/cache; deny everything else".
- You want a CNCF-Sandbox project with broad LSM-backend support (AppArmor / SELinux / BPF LSM) selectable per host.
- Your SecOps team owns policy authoring and tuning.
Pick Tetragon when
- Cluster-wide detection telemetry is the question - "show me every exec, every namespace transition, every capability use, with millisecond resolution".
- You already run Cilium and want the eBPF observability story to extend to runtime security.
- You need TracingPolicy CRDs to integrate with existing detection-pipeline tooling.
Compose all three when
- You operate regulated EU workloads on managed Kubernetes (EKS / GKE / AKS) at scale, and the audit surface needs all three layers - secrets sovereignty (cloudtaser), workload policy (KubeArmor), detection telemetry (Tetragon) - signed off independently.
Composition, not competition.
If your stack already runs KubeArmor or Tetragon and your DPO is asking the secrets-sovereignty question, that is exactly where cloudtaser slots in. Start with the deployment guide; the syscall exception list for KubeArmor and Tetragon co-residency is documented there.