test(e2e): cover workload identity against a real JWKS fetch

[lakhansamani]

Requested alongside #781. Closes the coverage gap that PR's finding exposed.

The gap

The RFC 7523 client_assertion path had no test where Authorizer actually fetches the signing keys. Every in-package test substitutes the fetch seam — which removes the single thing that decides whether the feature works in production: the address.

mock-oauth stands in for the cluster. It already generates an RS256 keypair, serves /jwks and has discovery, so it only needed an endpoint minting a JWT shaped like a projected ServiceAccount token. Four cases:

• a workload authenticates as its bound service account
• an assertion is single-use (replay refused)
• a subject outside allowed_subjects is refused
• a wrong-aud assertion is refused

Becoming the third caller of SafeHTTPClientAllowPrivate

The mirror is a compose-network service on a private address, so this needs the escape hatch — gated on Config.Env == E2EEnv, exactly as the SSO broker and webhook delivery already are. That function's doc comment asks for careful review before a third caller, so:

Why one is needed at all. Workload identity is Authorizer fetching a key document the operator points it at. Without this, the only end-to-end coverage of that fetch is no coverage.

Why the alternatives are worse. Relaxing the guard's ranges weakens a production control for a test. Hosting the mirror on a range the guard happens to permit couples the suite to a gap in the block list — there were two, and #781 closes them — so that approach loses its coverage the moment the gap is fixed correctly.

What is not relaxed. Scheme allow-list, one-shot DNS resolution and dial pinning (rebinding defence), redirect refusal, size cap, TLS verification. This widens which addresses are reachable and nothing else — the same trade, under the same flag, as the two existing callers.

The gate is asserted by outcome, not by reading the flag. A private address must be refused under production, under an empty env, and with a nil Config; and must be genuinely reachable (a real request, not just client construction) under e2e. An inverted condition, a drifting default, or a nil Config arriving from a new call site all fail there.

A false claim found while building it

The replay comment said K8s ServiceAccount tokens carry no jti, and justified the (iss,sub,iat,exp) fallback with it. Verified against a live cluster:

claims : ['aud', 'exp', 'iat', 'iss', 'jti', 'kubernetes.io', 'nbf', 'sub']
has jti: True

They do carry one. The fallback is still correct to keep — RFC 7523 permits omitting jti, and without the fallback such an assertion would have no single-use key at all — but not for the stated reason. Corrected in the code comment and the test comment; the docs repo copy is corrected in authorizerdev/docs#92.

The mock mints a jti for the same reason: real tokens have one, and without it two mints in the same second collide on the fallback key — which is exactly how the single-use test failed before I added it.

Verification

make test                exit 0 — 43 packages, 0 FAIL
make lint                exit 0
go build / go vet        OK
workload-identity.spec   4 passed (full compose stack, real fetch)