feat(unleash): send the pre-shared key to bifrost

[Starefossen]

Draft — not for merge yet. Part of the nais/bifrost#576 rollout.

The key now exists in fasit: nais/nais-terraform-modules#1561 is merged.

Context

bifrost added pre-shared-key authentication (nais/bifrost#549) and runs in its accept phase: unauthenticated calls are allowed but logged and counted. Verified in production:

warning  Request without a valid API key allowed (authentication not enforced)
bifrost_api_auth_requests_total{outcome="unauthenticated_allowed"}

nais-api is bifrost's only caller, so it is the gate on enforcement.

The chain

Step	Where	State
Key minted and written to fasit	nais/nais-terraform-modules#1561	merged
bifrost reads it	Feature.yaml → backend.auth.apiKeys	already wired
nais-api reads it	Feature.yaml → unleash.bifrostApiKey	this PR
Becomes an env var	secret.yaml → UNLEASH_BIFROST_API_KEY via existing envFrom	this PR
Client sends it	Authorization: Bearer <key> on every request	this PR
Enforcement toggle	nais/bifrost#579	draft

The key lands in the release Secret rather than as a plain value in deployment.yaml, alongside HOOKD_PSK and REST_PRE_SHARED_KEY — same kind of value, same handling. It still reaches the container as an env var.

Per-environment staging

unleash.bifrostApiKey defaults to the management value but can be overridden or cleared per environment, following the aiven.token pattern in the same file. Clearing it sends no credential, which bifrost accepts until it enforces — so one environment can be taken out of the rollout without touching the others.

Together with nais/bifrost#579, which makes backend.auth.enforced a per-environment toggle, that is what allows dev to go first: send the key in dev, confirm the unauthenticated counter goes flat there, enforce in dev only, then repeat.

Three commits

2deb514c threads the key to both places a real client is constructed — the GraphQL dataloader and the issue checker — so no path is left unauthenticated. The fake client used locally and in tests is untouched.

An unset key sends no header at all, not an empty one. A present-but-empty credential is worse than none: bifrost would record a failed authentication rather than an unauthenticated caller, which is harder to read during a rollout. Startup logs a warning when the key is missing, since that is the state that breaks when enforcement is flipped.

4c9309e9 wires the chart. The first commit read the env var but nothing set it — the client would have logged "No bifrost API key configured" and kept sending unauthenticated requests, so the rollout would have looked complete while changing nothing.

8012824b adds the per-environment override described above.

Behaviourally inert today

bifrost accepts both authenticated and unauthenticated calls, so merging this changes nothing user-visible. It only moves nais-api out of the warning log — the signal nais/bifrost#576 step 4 waits for.

Verification

go build ./... clean, internal/unleash tests pass. New tests assert the header is sent with the configured key and that no header is sent without one; the first fails if the request editor is removed. Chart renders with the key present; Feature.yaml parses.