feat: the node knows whose code it profiles (ADR 0059)

[kfeofantov]

Closes, for the eBPF capture path, the defect #93's ADR named as open.

The defect

The symbol filter classifies a frame by module path: no domain → stdlib or unpublished code, keep; allow-listed prefix → keep; anything else → third-party, redact. A customer's service lives under github.com/acme/web, which has a domain.

So the configured list was never an addition to what the filter knew — it was the only thing standing between the customer's service layer and [filtered]. Name one prefix, run five services, redact four.

The information was already there, in the same process

cmd/agent/node.go runs the scanner, which reads every kept binary's main module and every replace-redirected dependency, per container, every pass. cmd/agent/pipeline.go:60 ran the profiler beside it and built one filter for the whole node, from configuration alone. Two goroutines in one process that never spoke.

• The scanner now publishes a container → own modules index, replaced wholesale per pass so a container no live process belongs to leaves with it. Same shape internal/targeting uses on the controller, and for the same reason.
• processWindow — which already grouped by container — builds the filter per group: configured prefixes plus that build's own modules.
• A container the scanner has not reported yet (the first window can outrun the first pass) falls back to the previous behaviour, and Validate already refuses a profile of nothing but the runtime. No new drop rule for a case the existing one covers.

Two things worth a look

An allow-list entry that cannot be a module path is now refused. Part of the list comes from binaries, so a build declaring its main module as a bare github.com would otherwise admit every module hosted there. The same check applies to a prefix an operator wrote, where the same typo was previously accepted — that is a behaviour change for a misconfigured install and it is named in the ADR rather than left to be found.

This is not a defence against a hostile workload: a binary that lies exposes its own dependency frames to the party the customer already trusts with its profiles. It bounds a plausible typo.

The chart stops requiring allowedModulePrefixes for ebpf. That refusal existed because an empty list produced nothing, forever, silently. That stopped being true. A required value that changes nothing is the inert knob ADR 0025 abolished — so ebpf now installs and produces useful profiles with no profiling configuration at all, which is what inventory + pull has done since #93.

Why nobody saw it

test/e2e/capture_test.go set allowedModulePrefixes: [sampleModulePath] — the e2e was configured around the bug. It now installs with the allow-list absent, so a surviving frame of the sample can only mean the node read the module off the binary. That is the load-bearing change in this PR's test surface.

Also

OwnModules moves into nodescan, so the derivation that both paths depend on exists once instead of once per consumer.

Evidence

• TestOwnCodeSurvivesWithNothingConfigured ships a profile through processWindow with an empty configured list and asserts the workload's frame survives and the dependency's does not; TestWithoutTheIndexTheSameWindowShipsNothing pins the old behaviour beside it.
• TestOnlyAPlausibleModulePathIsAnAllowListEntry and TestTheFilterDropsAnImplausibleEntry cover the guard.
• go test ./... and golangci-lint run ./... pass on host and GOOS=linux, 0 issues.
• e2e not run locally (Docker is yours).

Still open, and stated in the ADR

The eBPF capture path contributes nothing to collection_coverage. The prober and puller each report what they attempted and why it failed (#92, #93); the profiler's refusals live only in the node's log. So "this workload has no eBPF profile" is still indistinguishable from a broken agent — exactly what ADR 0054 exists to prevent. Separate slice.

🤖 Generated with Claude Code

https://claude.ai/code/session_011YRKuL97KRndaopfpixrhp