How cloudtaser works, layer by layer.

The provider's trust boundary starts at entrypoint rewrite.

A mutating admission webhook intercepts pod creation, resolves the container's original entrypoint from the OCI registry, and rewrites command to launch through the cloudtaser wrapper. From that moment forward, the app's address space holds secrets that are unreachable by any process the provider controls.

How the webhook rewrites a pod

On CREATE or UPDATE of a pod carrying cloudtaser.io/inject: "true", the webhook queries the container registry (supporting private registries via imagePullSecrets) to resolve the image's original ENTRYPOINT and CMD. It injects a read-only init container that copies a single static wrapper binary into an emptyDir, then overwrites the main container's command to launch the wrapper with the original entrypoint as arguments.

The webhook verifies the image digest comes from a trusted registry before mutating. Injected containers automatically receive hardened pod security: seccomp: RuntimeDefault, readOnlyRootFilesystem: true, and explicit resource limits. No CRDs are required - the wrapper's configuration travels in annotations.

The wrapper as PID 1

At pod start, the wrapper runs as PID 1. It authenticates to the secret store (Kubernetes auth or token auth, mTLS-unsealed), fetches the secret paths listed in cloudtaser.io/secret-paths, and allocates each value into a memfd_secret(2) file descriptor. These file descriptors are special: their backing pages are physically removed from the kernel's direct memory map and cannot be re-mapped by any process including the kernel itself.

The wrapper then fork+execs the original application and stays alive as the parent - renewing vault tokens, renewing secret leases, re-fork+execing on rotation, and forwarding signals. Total footprint: one pure-Go binary, ~400 lines, zero native dependencies, no sidecar container.

Transparent delivery via execve() inheritance

The child inherits its environment - including secret values - through the standard Unix execve() mechanism. Applications call getenv("DB_PASSWORD") / os.Getenv / process.env and receive the secret value with zero source changes. This works for all binaries - including statically-linked Go (CGO_ENABLED=0), Rust x86_64-unknown-linux-musl, and hand-compiled -static C. No dynamic linker required. No SDK required. No Dockerfile edits.

The asterisk is sensitivity, not compatibility: once delivered, the secret is present in /proc/PID/environ of the child process. The wrapper's dumpable=0 raises the kernel-enforced procfs barrier; the eBPF layer detects cross-process reads of /proc/PID/environ and blocks them synchronously on kernels with CONFIG_BPF_KPROBE_OVERRIDE=y (e.g. Ubuntu 24.04). On kernels without that config (e.g. GKE COS), the eBPF layer detects and logs the attempt - detection is active everywhere; synchronous block is kernel-dependent. If your threat model rejects the env-var intermediate entirely, the optional cloudtaser Go SDK reads directly from the wrapper's memfd_secret FD - one import, one-line replacement for os.Getenv.

Memory protection beyond memfd

Three additional hardenings layer on top of memfd_secret(2):

• mlock(2) - locks secret pages in RAM so they are never paged to swap. cloudtaser_REQUIRE_MEMFD_SECRET strict mode refuses to start on kernels without memfd or when mlock limits are insufficient - fail-fast rather than silent degradation.
• PR_SET_DUMPABLE = 0 - excludes secret pages from core dumps so crash reports never contain credentials, even if the application ends up on a shared filesystem.
• PID pre-registration - the wrapper registers child PIDs with the eBPF agent over a Unix domain socket before exec(), closing the zero-second gap between process start and enforcement activation.

Supported container images

Because the webhook resolves the original entrypoint from the OCI registry, any base image works: scratch, distroless, Alpine, Debian, Ubuntu, RHEL, Wolfi, custom. No Dockerfile edits, no Helm template changes, no sidecar config files to render. Three annotations on the deployment and a kubectl rollout restart.

Layered enforcement. 35+ vectors, continuously active.

Two layers compose. First the wrapper sets PR_SET_DUMPABLE=0 on every protected process - that one prctl flips /proc/$pid/mem to mode 0600 owner-only and routes every external ptrace attach through ptrace_may_access, which the kernel denies same-namespace. Second the eBPF agent runs as a least-privilege DaemonSet - not with privileged: true, but with explicit capabilities (CAP_BPF, CAP_PERFMON, CAP_SYS_ADMIN where strictly required). It attaches to more than twenty kernel hooks covering the residual CAP_SYS_PTRACE-elevated bypass paths and the broader memory-read syscall surface - logging exfiltration attempts in real time. Where CONFIG_BPF_KPROBE_OVERRIDE=y is enabled (the kernel-side prerequisite for kprobe override), the hooks return -EPERM synchronously; on kernels without that config (e.g. GKE COS default node image), detection is active but synchronous blocking is not. BPF-LSM active enforcement, which does not depend on kprobe override, is in beta and ships default-on in v0.6 for kernel 5.15+.

Blocked attack vectors

• /proc path hardening - 12+ procfs paths monitored at open() via kprobe: mem, maps, smaps, environ, syscall, stack, pagemap, auxv, clear_refs, map_files, and more. Access attempts are logged and synchronously denied on kernels with CONFIG_BPF_KPROBE_OVERRIDE=y; detected and logged on all other kernels.
• ptrace attach - ptrace() syscall denied for protected PIDs. Standard debugger attach path is closed.
• perf_event_open - hardware watchpoints denied; the breakpoint-triggered read path is closed.
• io_uring submission queues - ring setup and submit intercepted via tracepoints, preventing async I/O bypass of seccomp filters.
• userfaultfd - userspace page-fault side-channel closed via syscall denial on protected PIDs.
• Global kernel module and eBPF program loading - init_module and bpf(BPF_PROG_LOAD) are watched system-wide, not just per-process. Loading a rogue LSM or kmod to read memory fires an alert regardless of which process does it.
• Spectre/Meltdown mitigation verification - agent reads /sys/devices/system/cpu/vulnerabilities/* at startup and feeds the result into a per-node protection score. Nodes with disabled mitigations are flagged.

Where the attack surface ends

After these vectors, the only remaining path to reading a protected secret is hypervisor-level physical memory access. In a typical cloud deployment the provider controls the hypervisor and can, with non-trivial effort, read guest physical memory. This is the surface cloudtaser cannot close alone. Closing it requires the CPU itself to enforce memory isolation from the hypervisor - AMD SEV-SNP, Intel TDX, or ARM CCA - which AWS, GCP, and Azure are rolling out as "confidential computing" node types. cloudtaser runs unchanged on confidential compute and closes the remaining gap.

Observability

The agent exposes 7 Prometheus metrics at /metrics:

• cloudtaser_protected_processes_total - gauge
• cloudtaser_enforcement_denials_total{vector=...} - counter, per-vector
• cloudtaser_proc_access_blocked_total{path=...} - counter
• cloudtaser_privilege_escalation_attempts_total - counter
• cloudtaser_protection_score - gauge, per-node
• cloudtaser_memfd_pages_locked_bytes - gauge
• cloudtaser_cpu_mitigations_enabled{name=...} - gauge

Zero-gap registration

The wrapper registers its child PID with the agent over a Unix domain socket before the exec() that launches the application. The agent's eBPF fork tracker then follows any descendants automatically. This closes the millisecond-level window between process start and policy activation that would otherwise exist - at no point is a protected process unobserved.