OCI image trust for Linux host observability
Inspektor Gadget ships eBPF gadgets as OCI images, which makes deployment familiar but shifts trust to the image supply path. That is a neat trick until someone treats “pulled successfully” as the same thing as “safe to run”. Once the gadget lands on a Linux host or Kubernetes node, it is close to the kernel and close to the data you are trying to observe.
Where the trust boundary sits when gadgets ship as OCI images
OCI image trust starts before execution. A signed image can still contain the wrong code, the wrong build inputs, or a gadget that behaves badly once it reaches a privileged host. If you are using Inspektor Gadget for Linux host observability, the image is only one part of the boundary. The other part is the privilege needed to load and run eBPF.
Signed images are not the same as safe execution
A signature tells you where an image came from, not whether the gadget inside is appropriate for the target machine or safe for the current context. A pulled image can still be a bad fit for the node, a poisoned build, or a deliberate attempt to interfere with monitoring. That matters more when the output is used to make operational decisions, because bad telemetry is a tidy way to hide a mess.
Root, CAPSYSADMIN, and why loading eBPF changes the stakes
Loading eBPF needs root, or at least CAPSYSADMIN. That is not a minor permission bump. It puts gadget deployment in the same class as other privileged host actions, where a mistake reaches past the container boundary and into the kernel-facing part of the machine. On Kubernetes nodes, that also means the blast radius can jump from one workload to the whole node if access is loose.
Build, deploy, and runtime paths that deserve separate controls
Treat the build, the image source, and the runtime channel as separate trust points. They fail in different ways and need different controls. One sloppy default in the build path does not get fixed by a signed image later.
Treat ig build inputs as code, not metadata
The build step is part of the attack surface. The published issue in ig build came from Makefile variable interpolation, which means attacker-controlled values could be pushed into shell execution during gadget builds. If build variables are coming from CI, a local script, or any untrusted source, handle them as code. Keep them pinned, validated, and boring. Boring is cheaper than a compromised runner.
The fix landed in v0.51.1, with the build logic moved from Makefile-based interpolation to Go. That is the sort of change that looks dull in a changelog and saves a headache later.
Pin image sources, enable TLS on ig daemon, and avoid insecure defaults
Image sources should be pinned. Pulling latest for a gadget that can run close to the kernel is the sort of habit that feels quick right up until it is not. The daemon side matters too. ig daemon can run with TLS, but it must be enabled with a flag, and the default channel is insecure. If you are shipping gadgets across a network listener, do not leave that as a casual default. On a shared lab, that is how someone else gets to poke at your observability stack.
Verify the monitoring path stays intact under load and hostile output
Observability falls apart in two ugly ways: event loss and poisoned output. One hides the thing you wanted to see. The other makes the terminal lie about what it saw.
Watch for dropped events before you trust the data
All gadget events pass through a single kernel ring buffer, hard-coded to 256KB in the audited setup. Flood it and the collector starts dropping events. Before the fix, those drops were ignored by the user-space collector, which made silent loss more dangerous than noisy failure. An attacker does not need a clever payload if they can fill the buffer with harmless noise and then act while the real events vanish.
Tracking dropped packets fixes the obvious blind spot, but the operational rule stays the same: watch for loss, not just output volume. If the event path can be flooded, the absence of data is not a clean bill of health.
Sanitize terminal output and keep Kubernetes node access narrow
Default columns output printed event text straight to terminals, which left room for ANSI escape sequences to alter or erase what the operator thought they were reading. That varies by terminal, which is another lovely little source of inconsistency. Sanitising terminal text closes off the easy abuse cases, but it only helps if the person reading the output can trust the screen in the first place.
Keep access to Kubernetes nodes narrow. Gadgets that inspect namespaces such as kube-system can see more than a casual debug session should expose. If you do not need broad node access, do not hand it out just because the tool is handy. Convenience has a way of becoming policy by accident.
