test: the collection listing is proved from inside the pod and refused from outside (ADR 0084)

[kfeofantov]

Follow-up to #125, which shipped the listing without an e2e test. Two of its claims are properties of a deployed agent rather than of a handler, so the unit tests cannot settle either:

• The names and reasons are right when the owner chains, namespace annotations and the pod set come from a real API server rather than a fake.
• What the chart actually binds is reachable from inside the pod and from nowhere else.

How it is asserted

The controller's spool-reader sidecar shares the pod's network namespace — which is the whole of what loopback grants — so it reads 127.0.0.1:9091/collection with no port, no NetworkPolicy and no credential. A second pod, in another namespace, then asks the controller's own address and must be refused at connect.

The install allows one fixture namespace, so all three answers appear in one run: a collected pod, a pod that opted itself out, and everything else refused by the configuration.

Evidence

make collection-e2e   # PASS 4.4s
  the listing carries 23 objects
  excluded: Pod/<fixture>/self-opted by pod_annotation
  excluded: Namespace//kube-system by namespace_filter
  a pod in <fixture> asking http://10.244.0.38:9091/collection:
    wget: can't connect to remote host (10.244.0.38): Connection refused

make policy-e2e       # PASS 64s — the refactored exec still reads the spool
go test -race ./... && golangci-lint run   # 0 issues

Also in here

Exec against one container of one pod was written twice. execSpoolReader now names its container and delegates to execIn.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KeZECJXTDHL6Nts95eKMJA