Kernel Compatibility¶

Check the running kernel, not the distribution's LTS label

Linux 7.0 is unsupported. Stock GCE ubuntu-2404-lts-amd64 booted 7.0.0-1014-gcp and the agent crash-looped. Run uname -r on every node. GKE COS 6.12.105+ passed secret delivery. Ubuntu 24.04 with linux-image-gcp-lts-24.04, kernel 6.8.0-1071-gcp, and bpf added to the lsm= boot line passed admission and startup only, without a store. An LTS image name or a newer kernel alone does not establish compatibility.

cloudtaser's eBPF agent provides three layers of runtime enforcement, each with different kernel requirements. The agent detects kernel capabilities at startup and reports which enforcement vectors have a synchronous deny path on the node.

Kernel capability is not deployment qualification

The default chart requires active BPF LSM (ebpf.requireLSM=true) and refuses health/readiness while required enforcement gaps remain (ebpf.failClosedOnEnforcementGap, effectively true through its deprecated alias). The measured GKE Ubuntu 6.8.0-1062-gke image fails the active-LSM prerequisite. The 29 October COS 6.12.105+ test passed default strict readiness with Tier 1 lsm+fmod_ret. Consult the measured platform matrix for the exact cohort and qualify each node image and release.

Enforcement Layers¶

Mechanism	Prerequisites	Evidence boundary
BPF LSM synchronous deny	BPF LSM built and active; relevant hook attached and effective	Covers the hook's actual operations, not every required vector
Kprobe override synchronous deny	`CONFIG_BPF_KPROBE_OVERRIDE=y` and an error-injection-allowlisted target	Availability must be proved for each required target
`fmod_ret` synchronous deny	Function-error injection support and an eligible target with an effective attachment	Measured on COS with `lsm+fmod_ret`; verify each required vector on the deployed release
Detection / reactive response	Vector-specific tracepoint and response policy	Does not establish synchronous denial; response depends on caller and vector

The released agent used fmod_ret in the measured COS deployment. Kernel CONFIG_FUNCTION_ERROR_INJECTION alone does not prove that an eligible hook is attached: inspect the agent's reported mechanisms, vector states and readiness.

Kernel Support Matrix¶

Per-distro kprobe-override capability¶

Use the measured platform matrix and pinned sources as the current reference. Distribution names and a single kernel option do not establish readiness.

GKE node image	Evidence	Current default outcome
Ubuntu 24.04.5, `6.8.0-1062-gke`	Kprobe override enabled, BPF LSM built, active LSM list excludes `bpf`	Startup refused by `requireLSM`
COS `6.12.105+`, live test on 29 October	Active BPF LSM and `fmod_ret`; kprobe override unavailable	Tier 1, Ready with default strict settings; other COS images need their own qualification

CI-Validated Kernel Matrix¶

Kernel CI validates the capabilities and boot arguments of its fixtures. A fixture carrying a cloud name is not proof that a stock managed node image has the same configuration or active LSM stack. In particular, a GKE Ubuntu guest booted with BPF LSM does not qualify the measured stock Ubuntu image above. A COS-inspired fixture must match COS's enabled function-error injection; the live COS result above is separate evidence from any fixture.

Use the kernel digests and lane results pinned to the exact eBPF release you deploy. The eBPF pipeline shows the development matrix; inspect the corresponding release tag for installed versions. Historical kernel-version tables are not a substitute for those receipts or vendor-image evidence.

Managed Kubernetes Services¶

Cloud platform permissions, active LSM configuration and per-vector enforcement are separate requirements. Follow the GKE guide for current refusal diagnostics and the platform matrix for other providers. Do not infer support from a CI fixture, a node label or a protection score.

How to Check¶

Check the kernel config (before or after installing cloudtaser)¶

Through your approved node-access procedure, inspect the running kernel configuration and cat /sys/kernel/security/lsm. The active list must include bpf; a built-in option or successful probe load alone does not establish an active LSM path.

Ubuntu / Debian (/boot/config)Any kernel exposing /proc/config.gzWhen neither of the above worksInventory across the cluster

grep CONFIG_BPF_KPROBE_OVERRIDE /boot/config-$(uname -r)

Kprobe override requires CONFIG_BPF_KPROBE_OVERRIDE=y, plus an eligible target. An explicit unset disables this mechanism. Empty output or a missing config file is missing evidence, not proof that the feature is absent or enabled.

zcat /proc/config.gz 2>/dev/null | grep CONFIG_BPF_KPROBE_OVERRIDE

Availability of this file depends on the running image; inspect its provenance when using a separately supplied config.

# Node has neither /boot/config-* nor /proc/config.gz
# Only through an approved node-inspection environment
bpftool feature probe kernel 2>/dev/null | grep -i kprobe_override

A feature probe is supplemental evidence. It does not prove bpf is active in the LSM stack, that a target allows override, or that the agent has complete coverage. Do not treat unreadable securityfs as a successful active-LSM check.

# List every node and its kernel version -- useful for heterogeneous clusters
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kernelVersion}{"\t"}{.status.nodeInfo.osImage}{"\n"}{end}'

Pair each row against the per-distro table above. Any row you cannot map → run one of the host-side checks.

Check what YOUR cluster is actually doing¶

Inspect each eligible node's agent, not just one DaemonSet replica:

kubectl get pods -n cloudtaser-system -l app.kubernetes.io/name=cloudtaser-ebpf -o wide
kubectl logs -n cloudtaser-system -l app.kubernetes.io/name=cloudtaser-ebpf --tail=100

Using the configured TLS and authentication, inspect /status kernel_tier and /healthz enforcement_vectors, plus the /readyz result and enforcement_gaps. A startup log with kprobes_active: true or a nonzero lsm_count is insufficient to qualify every vector. Compare reported states with the actual active LSM list and the release's retained enforcement evidence; #1199 tracks current classification and active-stack probe corrections.

Keep the result per node, with its kernel version, image and exact component digests. A mixed pool must not schedule protected workloads onto an unqualified node merely because another node passed.

What to do if the agent reports an enforcement gap¶

Keep the workload outside migration until the exact node image and released agent meet the required enforcement policy. Inspect the active LSM list, /healthz enforcement_vectors and /readyz gap reasons. The measured COS node meets the default readiness policy through lsm+fmod_ret; the measured GKE Ubuntu image lacks active BPF LSM. Do not choose a node image from its kprobe-override column alone.

Do not disable the gates to make a readiness check pass. Any accepted-gap configuration needs a reviewed, explicit scope and matching release evidence.

Compliance Implications¶

Retain audit events alongside enforcement and readiness evidence. An audit trail or score alone does not establish regulatory compliance or synchronous denial. The default readiness gate requires every required vector to have the reported synchronous path.

For an operation actually covered by the mechanism:

	Synchronous Block	Reactive Kill
Data leaked?	No	Possible: the read completes before the kill
Process killed?	No (syscall fails cleanly)	Yes (SIGKILL)
Audit event logged?	Yes	Yes
Satisfies the default readiness policy?	Only when all required vectors are covered	No, not on its own

Whether a given mode satisfies a particular regulation is your assessment to make. This page does not claim that reactive kill is sufficient.