ADORSYS-GIS / ADORSYS-GIS/lightbridge-governance

[Ticket]: Codex and VS Code telemetry needs a second accepted credential after the audience narrows

Open
#144 0 comments 0 reactions 0 assignees View on GitHub
ticket
Dominant language
Rust
Stars
1
Forks
2
Avg merge
13h 13m
Merged PRs (30d)
110

Description

### Type
Ticket

### Summary

Once `aiCliOtel`'s OIDC audience narrows to `governance-auth-cli` (#142), Codex and VS Code
Copilot can no longer push telemetry at all. They need a second accepted credential —
either a second receiver/oidc extension trusting `lightbridge-api-key`, or another design
that gives them a refreshable token.

### Why they break

Neither has a credential-helper hook for OTLP headers. Claude Code does
(`otelHeadersHelper`), so `governance-auth otel-headers` can hand it a short-lived
exchanged token on an interval. Codex and VS Code read their OTEL config **once at process
start**, so the only thing that works for them today is the static `--otel-token`: a
long-lived (120d) lightbridge-authz API key carrying `aud: lightbridge-api-key`.

#142 narrows the collector to `aud: governance-auth-cli`, which those keys do not carry, so
they are rejected. This is #84 AC 4, accepted explicitly rather than left undecided.

VS Code is worse off still: it exposes the OTLP endpoint as a *setting* but authentication
**only** via the `OTEL_EXPORTER_OTLP_HEADERS` environment variable, so no file
`governance-auth` writes can supply its credential — `otel.rs::vscode_manual_env` exists
precisely to print the `export` line a human must run.

### Source of truth

- #84 — the parent bug and its AC 4.
- #142 — the audience narrowing that triggers this (currently draft).
- `charts/lightbridge-governance/values.yaml`, `aiCliOtel.oidc` — the comment there records
the same consequence.
- Live evidence: collector logs show `missing or empty header` from clients sending no
credential, alongside `failed to verify id token signature` from Claude Code.

### Not yet decided — this ticket should choose

1. **Second receiver/extension** trusting `lightbridge-api-key` alongside the
`governance-auth-cli` one. Restores today's behaviour. Cost: two trust paths into one
pipeline, and the long-lived-key exposure stays.
2. **Register the API-key audience as an additional client** so one receiver covers both.
Needs checking against ADR-0011 Decision 5 — `aud` is always the requesting `client_id`,
so this may not be expressible.
3. **Accept the gap**: only Claude Code reports telemetry until Codex/VS Code grow a
refresh hook. Cheapest, and honest, but `docs/integrations/ai-client-support-matrix.md`
must then stop claiming those paths work.

### Acceptance criteria

- [ ] A decision is recorded (which option, and why) rather than a receiver being added by
default.
- [ ] If a second credential path ships, an unauthenticated or wrong-audience push still
gets a generic 401 — no detail leaks about which audience would have worked.
- [ ] `docs/integrations/ai-client-support-matrix.md` matches the true end state, whichever
it is. It currently describes Codex/VS Code telemetry as working; after #142 that is
false until this is resolved.
- [ ] Verified by a real OTLP push per client, not by the collector merely starting.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.