Send instance name as x-api-key to the OTLP relay#316
Draft
archandatta wants to merge 1 commit into
Draft
Conversation
The metro-api OTLP relay authenticates a VM by its instance name checked against active sessions (mirroring the capmonster/hcaptcha relays), so send INST_NAME as x-api-key instead of the instance JWT as a bearer token. Drop the now-unused KERNEL_INSTANCE_JWT exporter config (the env still exists for the envoy wrapper; the exporter just no longer reads it). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Aligns the in-VM OTLP exporter to the metro-api relay's auth contract. The relay authenticates a VM by its instance name checked against active sessions (the same model as the capmonster/hcaptcha relays), so the exporter now sends
INST_NAMEas thex-api-keyheader instead of the instance JWT as a bearer token. The now-unusedKERNEL_INSTANCE_JWTexporter config is dropped (the env still exists for the envoy wrapper — the exporter just no longer reads it).Companion to the metro-api relay PR (kernel/kernel#2763). Wire contract:
x-api-key: <instance_name>+ POST toBTEL_OTLP_PATH(set to/otlp-relay/v1/logsby provisioning when pointing a VM at the relay).Why
The relay decides which org's destination + credentials to use from the instance identity. Verifying an instance JWT signature would require plumbing
XDS_JWT_SECRETinto metro-api (which has no such secret today and verifies no instance-JWT signatures) and would make the relay the odd one out among sibling relays. Instance names are unguessable cuid2 pairs gated on an active session, sox-api-keyis the consistent, sufficient credential.Changes
server/cmd/api/main.go:Authorization: Bearer <InstanceJWT>→x-api-key: <InstanceName>.server/cmd/config/config.go: remove theInstanceJWTfield and itsLogValueredaction.Test plan
go build ./...andgo test ./cmd/config ./lib/eventsgreen.Notes
archand/kernel-1213/otel-export, Add in-VM OTLP telemetry export sink #308) since that isn't merged yet; retarget tomainonce Add in-VM OTLP telemetry export sink #308 lands.401/403/404from the relay as a normal steady state. A later change can quiet those specific statuses inloggingExporter(needs confirming the status is cleanly extractable from theotlploghttperror) so they don't inflate the failure counter/logs.