feat: authenticate /v1, add resolve/client-id, and a deployable chart

[JamesReate]

Unblocks deploying this service at all. Two things stood in the way: /v1 had no
authentication, and there was no chart.

/v1 was completely unauthenticated

The route comment said it outright — "That middleware is not wired yet; the
route is registered so the contract is visible and testable." Harmless while
nothing was deployed; the moment it is, anyone able to reach the service can ask
for authorization decisions about any tenant.

Now: jwtware verifies developer-license JWTs against the DIMO JWKS, then a
resolver maps ethereum_address onto a tenant via
tenant_credentials.dimo_client_id.

The order is load-bearing, not cosmetic. Reversed, the claim would be
attacker-supplied and the resolver would authenticate anyone. There's a test
asserting an unauthenticated request cannot reach a handler, because that is the
property that matters.

Two deliberate differences from kaufmann's resolver

	kaufmann	here	why
Match	DimoClientID.EQ(addr)	lower(dimo_client_id) = lower($1)	Exactly the expression the unique index is built on, so lookup and uniqueness agree
Duplicates	qm.Limit(1)	none	kaufmann's schema permits duplicate client ids — its comment says they "shouldn't happen, but the data model allows it", and in production two pairs did. Here the unique index makes a duplicate a schema violation that should surface, not be truncated to whichever row sorted first

GET /v1/resolve/client-id/{clientId}

Listed in the spec; replaces kaufmann's in-app resolver, which stops being able
to answer once an operator's license is shared with its customers. Returns 404
for an unknown id — unlike /v1/authz, where "no access" is a 200, because authz
asks a question with a legitimate negative answer while this dereferences an
identifier that either exists or doesn't.

Chart

Deployment (with the migrate init container), service, config, ExternalSecret,
PDB, service account. Two omissions are choices, not oversights:

• No ingress. /v1 is cluster-internal by design. Publishing one would make
  a credential check the only thing between the internet and every tenant's
  authorization data.
• No ServiceMonitor. There is no /metrics endpoint yet, so scraping it
  would create a permanently-failing target and the alert noise with it.

Things found along the way

• No CI or build workflows existed, so no image was ever built — a chart
  alone would not have been deployable. Added both.
• Adding lint to a repo that had never run it surfaced 8 pre-existing errcheck
  findings. Fixed, so CI is green on its first run rather than red.
• The Dockerfile ignored the COMMIT_HASH build arg the workflow passes,
  running git rev-parse against whatever .git was in the build context —
  /version would have reported unknown in the shipped image.

Open decision, flagged in app.go rather than silently chosen

Authentication identifies which tenant is calling, but no handler restricts a
caller to asking about its own tenant. Tolerable only because the surface is
cluster-internal. Whether to enforce caller == subject depends on which license
the callers actually present — fleet-lite holds per-tenant credentials and could
present the subject's, which would make enforcement natural. CallerFrom exposes
the caller so a handler can log or enforce it without further plumbing.

Verification

go build, go vet, gofmt, golangci-lint (0 issues) and the full suite pass;
the DB-backed resolver tests ran against the real schema rather than skipping.
helm lint passes and the rendered chart was validated with
kubectl apply --dry-run against the live cluster — all six resources, including
the ExternalSecret CRD.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RifTN8ZabDWb1hW7XtBRcQ