Composing CloudTaser with Tetragon and KubeArmor

CloudTaser, Tetragon, and KubeArmor each address a distinct security domain. They compose without conflict when deployed correctly. This guide covers capability boundaries, deployment ordering, policy configuration, and the specific pitfalls to avoid.

---

Why compose?

CloudTaser provides data sovereignty -- secrets never touch etcd, disk, or any US-controlled storage layer. The eBPF agent blocks /proc reads, ptrace, and exfiltration syscalls on protected processes. Secrets are fetched from an EU-hosted OpenBao directly into memfd_secret-backed process memory.

Tetragon and KubeArmor provide behavioral security -- syscall auditing, process-tree visibility, file-system allow/deny policies, and LSM-based container hardening. They answer questions CloudTaser does not: "which processes ran inside this pod?", "did this container write to /etc/shadow?", "should this workload be allowed to call execve at all?"

These are complementary threat vectors:

Capability	CloudTaser	Tetragon	KubeArmor
Secret lifecycle (vault fetch, memfd storage, env injection)	Yes	No	No
EU data sovereignty guarantee	Yes	No	No
/proc/environ and /proc/mem blocking	Yes (eBPF kprobe/LSM)	Observable but not its purpose	Possible but not its purpose
Syscall-level process tracing and audit	No	Yes (TracingPolicy)	No
Process-tree visibility (parent/child chain)	No	Yes	Partial
File-system allow/deny per container	No	No	Yes (AppArmor/SELinux/eBPF-LSM)
Capability hardening per pod	No	No	Yes
Network policy (L3/L4/L7)	No	Partial (via Cilium)	Partial

Running all three gives you: sovereign secret management + runtime syscall audit trail + per-container file and capability lockdown. No single tool covers all three.

---

CloudTaser + Tetragon

No eBPF conflict

Both CloudTaser and Tetragon use eBPF, but they attach to different hooks and run as separate DaemonSets. The kernel's eBPF subsystem supports multiple programs on the same hook type via BPF link multiplexing (kernel 5.7+). In practice:

• CloudTaser's eBPF agent attaches kprobes to syscall entry points (openat2, ptrace, process_vm_readv, etc.) and uses bpf_override_return to block calls targeting protected cgroups.
• Tetragon attaches TracingPolicy-defined kprobes and tracepoints for observation and optional enforcement.

These programs are independently loaded and do not interfere. The BPF verifier validates each program in isolation. There is no shared map or shared state between the two DaemonSets.

Tetragon observes the CloudTaser exec chain

Tetragon's process-tree tracing naturally captures the CloudTaser wrapper's fork+exec sequence. This is useful for audit:

cloudtaser-wrapper (PID 1)
  └── execve("/usr/bin/myapp", ...)
        └── application process

Tetragon will record the wrapper as the parent, the exec call, and the application's full process lifecycle. This provides an independent audit trail that the wrapper launched exactly the expected binary.

Recommended configuration

Run Tetragon in observe-only mode alongside CloudTaser's enforcement eBPF. Tetragon's strength is visibility, not secret protection. Avoid adding Tetragon enforcement policies that duplicate CloudTaser's coverage.

Do:

• Use Tetragon TracingPolicies to audit execve, file opens, and network connections across all workloads.
• Feed Tetragon events to your SIEM for behavioral anomaly detection.
• Use Tetragon's process-tree data to verify that CloudTaser-protected pods run the expected binary.

Do not:

• Add a Tetragon TracingPolicy that enforces /proc/PID/environ blocking -- CloudTaser's eBPF already blocks it. Tetragon would observe the block (an -EACCES return), not a bypass.
• Add Tetragon enforcement policies on ptrace, process_vm_readv, or other syscalls that CloudTaser already blocks -- duplicate enforcement adds latency and creates ambiguous audit logs (two "blocked" events for one syscall).

Example: Tetragon TracingPolicy alongside CloudTaser

This policy audits file opens across all pods without interfering with CloudTaser's enforcement:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: audit-file-opens
spec:
  kprobes:
    - call: "fd_install"
      syscall: false
      args:
        - index: 0
          type: int
        - index: 1
          type: "file"
      selectors:
        - matchActions:
            - action: Post

This policy records file descriptor installations cluster-wide. CloudTaser-protected pods will show blocked /proc access attempts (the openat returns -EACCES before fd_install fires), giving Tetragon a clean audit record of enforcement events without overlap.

---

CloudTaser + KubeArmor

Policy enforcement layers

KubeArmor enforces container-level security policies via AppArmor, SELinux, or eBPF-LSM depending on the node's kernel and security module configuration. Its policies control:

• File-system access (allow/deny/audit per path)
• Process execution (which binaries may run)
• Network operations (per-container socket restrictions)
• Linux capabilities (drop/restrict per pod)

CloudTaser's wrapper and eBPF agent require specific capabilities and file access to function. KubeArmor's default-deny policies will break CloudTaser unless the cloudtaser-system namespace is explicitly exempted.

Required allowlist

CloudTaser components that KubeArmor policies must not restrict:

Component	Namespace	What it needs
Operator (Deployment)	cloudtaser-system	Webhook TLS, Kubernetes API access, broker connection
eBPF agent (DaemonSet)	cloudtaser-system	hostPID, hostNetwork, BPF syscalls, /sys/fs/bpf mount, /proc read for cgroup discovery
Wrapper (injected init container)	Application namespace	execve for the wrapped binary, outbound network to vault/beacon, memfd_secret syscall, mlock, prctl

Example: KubeArmor policy with CloudTaser namespace exemption

The following KubeArmorClusterPolicy applies a default file-system audit posture to all namespaces while exempting cloudtaser-system:

apiVersion: security.kubearmor.com/v1
kind: KubeArmorClusterPolicy
metadata:
  name: default-file-audit
spec:
  severity: 5
  selector:
    matchExpressions:
      - key: kubearmor.io/namespace
        operator: NotIn
        values:
          - cloudtaser-system
          - kube-system
  file:
    matchDirectories:
      - dir: /proc/
        recursive: true
        action: Audit
      - dir: /sys/
        recursive: true
        action: Audit
  process:
    matchPaths:
      - path: /usr/bin/curl
        action: Audit
      - path: /usr/bin/wget
        action: Audit

For the wrapper's init container running in application namespaces, ensure the KubeArmor policy allows:

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: allow-cloudtaser-wrapper
  namespace: my-application
spec:
  severity: 1
  selector:
    matchLabels:
      cloudtaser.io/inject: "true"
  process:
    matchPaths:
      - path: /cloudtaser/wrapper
        action: Allow
    matchDirectories:
      - dir: /cloudtaser/
        recursive: true
        action: Allow
  file:
    matchDirectories:
      - dir: /proc/self/
        recursive: true
        action: Allow
  network:
    matchProtocols:
      - protocol: TCP
        action: Allow

Do not block the wrapper's exec chain

KubeArmor process policies in Block mode will prevent the wrapper from executing the application binary if the wrapper path or application path is not in the allowlist. The wrapper uses execve to launch the application as PID 1 -- blocking execve for the wrapper container kills secret injection entirely.

---

What NOT to do

Do not substitute external policy tools for CloudTaser's eBPF enforcement

Tetragon and KubeArmor can both enforce /proc access restrictions. However, using them as a replacement for CloudTaser's eBPF agent removes a critical security property: CloudTaser's enforcement is cryptographically tied to the vault key lifecycle.

CloudTaser's eBPF agent:

• Tracks protected processes via cgroup-array membership, updated by the operator based on vault authentication state.
• Enforces only on pods that have active vault sessions -- if the vault token is revoked, the protection boundary is precisely defined.
• Uses bpf_override_return for synchronous blocking (no race window on kprobe-override-capable kernels).
• Is deployed, versioned, and updated as part of the CloudTaser Helm chart, ensuring the enforcement version matches the wrapper version.

External policy tools:

• Enforce based on Kubernetes labels, namespace selectors, or static policies -- disconnected from the vault authentication state.
• Can be modified or removed by a privileged attacker who has access to the Kubernetes API (the same attacker CloudTaser's threat model assumes).
• Do not have access to CloudTaser's secret-content maps for exfiltration detection.

Security boundary

A privileged attacker (root on node, CLOUD Act compulsion) who can modify KubeArmor or Tetragon policies can disable their enforcement. CloudTaser's eBPF programs are loaded by a DaemonSet with hostPID and pinned to /sys/fs/bpf -- removing them requires host-level CAP_SYS_ADMIN AND knowledge of the pinned program paths. On a node with the eBPF agent running, program detachment is itself a monitored and blocked operation (vector #27, BPF_LINK_DETACH).

Do not add CloudTaser's eBPF agent to a KubeArmor default-deny policy

The eBPF agent DaemonSet requires hostPID, access to /sys/fs/bpf, /proc for cgroup discovery, and the bpf() syscall. A KubeArmor default-deny policy on the cloudtaser-system namespace will prevent the agent from loading its programs, silently degrading the protection score to zero.

Do not run Tetragon enforcement on CloudTaser-monitored syscalls

Adding a Tetragon Sigkill action on the same syscalls CloudTaser's eBPF blocks (e.g., openat targeting /proc/PID/environ) creates two problems:

1. Race condition on reactive kill -- if Tetragon sends SIGKILL before CloudTaser's kprobe fires, the audit event in CloudTaser's log is lost. The syscall was blocked, but CloudTaser has no record of it.
2. Double logging -- if both fire, security tools downstream receive two "blocked" events for one syscall invocation, inflating incident counts and creating false audit trails.

---

Deployment ordering

Install CloudTaser before adding Tetragon or KubeArmor to the cluster.

Recommended order:

1. CloudTaser -- operator, eBPF DaemonSet, and wrapper via the unified Helm chart.
2. Tetragon -- install with default observe-only policies. Verify CloudTaser pods are visible in Tetragon's process tree.
3. KubeArmor -- install with the cloudtaser-system namespace exemption in place from the start.

Why this order matters:

• CloudTaser's mutating admission webhook must be registered before KubeArmor's admission policies. If KubeArmor's webhook fires first and rejects a pod spec that includes CloudTaser's init container (e.g., because it mounts a binary from an unrecognized path), the pod will fail to create with no indication that CloudTaser was involved.
• Tetragon's TracingPolicies should be written with awareness of CloudTaser's enforcement -- deploying Tetragon first risks writing policies that assume /proc reads succeed, then having those policies generate unexpected audit noise when CloudTaser starts blocking them.

Verify correct composition

After deploying all three, run this check:

# Verify CloudTaser eBPF programs are loaded
kubectl -n cloudtaser-system exec ds/cloudtaser-ebpf -- \
  bpftool prog list | grep -c cloudtaser

# Verify Tetragon sees CloudTaser-protected pods
kubectl -n kube-system exec ds/tetragon -- \
  tetra getevents -o compact | grep cloudtaser-wrapper

# Verify KubeArmor is not blocking CloudTaser components
kubectl -n cloudtaser-system logs ds/cloudtaser-ebpf | grep -i "permission denied"

---

Cost/benefit: all three vs CloudTaser-only

Deployment	What you get	Operational overhead
CloudTaser only	EU data sovereignty, memfd_secret memory isolation, 27-vector eBPF enforcement, exfiltration detection	One Helm chart, one DaemonSet, one operator
CloudTaser + Tetragon	Above + full syscall audit trail, process-tree visibility, behavioral anomaly baseline	Two DaemonSets, Tetragon policy management, SIEM integration
CloudTaser + KubeArmor	Above + per-container file/process/network lockdown, capability hardening	Two DaemonSets, KubeArmor policy management per namespace
All three	Complete stack: sovereignty + audit + container hardening	Three DaemonSets, two policy management surfaces, namespace-aware exemptions

For most regulated EU enterprises, CloudTaser + Tetragon provides the best balance: data sovereignty enforcement from CloudTaser and a deep audit trail from Tetragon that satisfies NIS2 Article 21(b) and DORA Article 10 monitoring requirements without the policy management overhead of KubeArmor. Add KubeArmor when your security policy requires per-container file-system lockdown beyond what Kubernetes SecurityContext provides.

---

Telemetry pipelines

Each tool ships events to its own backend by default. There is no shared telemetry surface:

• CloudTaser -- events logged to the eBPF agent's stdout (structured JSON), collected by the cluster's log pipeline (Fluentd, Vector, etc.) or forwarded to the SaaS platform.
• Tetragon -- events exported via its gRPC API or Hubble Relay to Grafana, Elasticsearch, or Splunk.
• KubeArmor -- events exported via its relay server to any supported SIEM.

No shared backend is assumed or required. If you run a unified SIEM, each tool's events can be correlated by pod UID and timestamp -- CloudTaser's ENVIRON_READ block event will share a timestamp with Tetragon's corresponding openat trace for the same syscall invocation.