vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

otel: stop handing hive-c0re the upstream auth credential

Browse source 
hive-c0re's container-resource exporter already targets this hive's own
collector (environment.nix derives the bridge address), so the upstream
header it was loaded with has nowhere to be presented: that hop is
unauthenticated for every producer on the host, and the credential
belongs to the swarm tier, which is the one that leaves the swarm.

Drop the LoadCredential entry and the auth_headers() reader with it.
The option itself stays -- swarm-otel.nix is its real consumer, via
EnvironmentFile on the collector unit.

Also corrects three descriptions that this makes false, or that were
already false: the module doc claimed to reuse the config "Claude Code's
in-container SDK export uses", which stopped being true when agents
moved off that path; the nix comment claimed the secret is "the same one
the agent containers get, forwarded via nspawn --load-credential", which
lost its last producer earlier; and docs/observability.md described an
Authorization header on a hop that will no longer send one. The
headersCredential option's own docs already said it reaches "neither an
agent container nor a hive's own collector" -- this makes that true
rather than aspirational.
This commit is contained in:
atlas 2026-08-18 23:06:14 +02:00 • committed by mara
commit 5ca5433e0b
3 changed files with 27 additions and 50 deletions
Download patch file Download diff file Expand all files Collapse all files

17
nix/host-modules/hive-c0re/default.nix
View file

@ -273,16 +273,13 @@ in
RuntimeDirectoryPreserve = "yes";
StateDirectory = "hyperhive";
StateDirectoryMode = "0750";
# OTEL auth-header secret, loaded onto hive-c0re's own unit so its
# per-agent container-resource metrics exporter can read it
# at $CREDENTIALS_DIRECTORY/otel-headers — via systemd, not a world
# path. Same secret the agent containers get (forwarded there via
# nspawn --load-credential); this just also hands it to c0re itself.
# Empty list (no credential) when otel is off or no header is set.
# No OTEL credential here. hive-c0re's container-resource exporter
# targets this hive's own collector, which takes unauthenticated OTLP
# on the bridge; the upstream header belongs to the swarm tier
# (`swarm-otel.nix`), the only hop that leaves the swarm. Handing it to
# the daemon as well would put a secret on a process that has nowhere
# to present it.
LoadCredential =
lib.optional (
config.services.hyperhive.otel.enable && config.services.hyperhive.otel.headersCredential != null
) "otel-headers:${config.services.hyperhive.otel.headersCredential}"
# The swarm-queue client secret this hive authenticates with to
# publish its own status. `LoadCredential` and not a copy: root
# reads the plaintext at unit start and hive-core sees it 0400
@ -290,7 +287,7 @@ in
# and the daemon never needs read access to wherever it lives.
# (The callout responder copies instead only because it
# delivers into a container, across a filesystem boundary.)
++ lib.optional (
lib.optional (
config.services.hyperhive.swarm.statusPublish.clientSecretFile != null
) "swarm-status-client.secret:${config.services.hyperhive.swarm.statusPublish.clientSecretFile}";
# Sandboxing. hive-c0re is unprivileged (runs as hive-core, never