Authorize routine dispatch by peer identity and harden the trust model

[conradbzura]

Description

#249 ("Support identity-based mutual TLS") and #251 ("Verify mutual TLS peers by SPIFFE workload identity") establish who a peer is: a connecting client or worker can be authenticated by a verifiable, address-independent workload identity. They answer authentication — "who are you" — but not what an authenticated peer is then allowed to do, and they assume mutual TLS is the only way to authenticate and that the discovery plane and the default posture can be left implicit.

This issue builds on that authenticated identity to close the remaining trust gaps as one coherent step:

1. Authorization by peer identity — a policy over which routines a given authenticated identity may dispatch, so authentication ("who are you") is paired with authorization ("what may you run").
2. Authentication without full mutual TLS — a per-dispatch credential, such as a bearer token, that a worker verifies, as a lighter-weight alternative to provisioning client certificates everywhere or as a second factor alongside mutual TLS.
3. Discovery-plane trust — a discovered worker is trusted only insofar as it presents a verified identity on connection, with the discovery threat model documented so advertisement spoofing cannot by itself redirect work.
4. Secure-by-default posture and guardrails — a clear signal when a worker serves an unauthenticated channel off-host, and a strict mode that refuses to run insecurely, with mutual TLS remaining the default.

In scope: the four behaviors above, layered on the authenticated identity from #249 and #251 and the existing dispatch, discovery, and pool paths.

Out of scope: the credential and identity mechanics themselves (delivered by #249 and #251). Richer policy engines, health-aware peer eviction, and audit-logging pipelines are natural extensions but are not required here; this issue establishes the authorization and posture surface, not a full policy framework.

This issue describes the expected behavior and deliberately leaves the design open. Where authorization decisions are evaluated, how a token is carried and verified, how the discovery threat model is enforced, and how strict mode is configured are for the implementing change to decide, provided the observable behavior below holds.

Motivation

Authentication alone is not access control. Once #249 and #251 let a worker confirm a peer's identity, every authenticated peer can still invoke any routine on the fleet — so a single compromised but legitimately authenticated client can run arbitrary code everywhere. A worker fleet that runs untrusted-adjacent, multi-tenant, or compliance-bound workloads needs least privilege: the ability to say that a given identity may dispatch only a specific set of routines. Authorization is the defense-in-depth layer that authentication cannot provide on its own.

Full mutual TLS is also not always the right authentication mechanism. Provisioning and distributing client certificates to every caller is heavy, and some deployments would rather authenticate callers with a bearer token — an OAuth token, a JSON Web Token, or a signed nonce — issued by infrastructure they already run, either instead of client certificates (one-way TLS plus a token) or as a second factor on top of mutual TLS. Wool offers no such mechanism today, so these deployments have no lighter-weight option.

Discovery, finally, is unauthenticated: anything that can advertise under a pool's namespace can present itself as a worker, and on an unauthenticated channel that is a direct work-redirection vector. Identity verification must be the explicit trust anchor for discovered peers, and the threat model must be written down rather than assumed. And because it is currently easy to run fully open — plaintext, reachable off-host, with no signal that the channel is wide open — the safe configuration should be the easy and default one, with insecure configurations either warned about or refused.

Expected outcome

Authorization by peer identity

• An operator can configure a policy that authorizes which routines a given authenticated peer identity may dispatch — for example, an allow-list of routine names per worker or pool, or a decision hook evaluated on the peer identity together with the requested routine.
• A dispatch from an authenticated peer for a routine its identity is not authorized to invoke is rejected before the routine executes, and the rejection is distinct and observable — distinguishable from a routine raising an error and from a transport failure.
• Authorization decisions key on the verified identity from Verify mutual TLS peers by SPIFFE workload identity #251 (and on the token identity below, where that is the authentication mechanism), so the same identity model drives both authentication and authorization.
• With no policy configured, behavior is unchanged from today: any authenticated peer may dispatch any routine. Authorization is opt-in and additive.

Authentication without full mutual TLS

• A client can attach a per-dispatch credential — a bearer token such as an OAuth token, a JSON Web Token, or a signed nonce — to the dispatches it sends.
• A worker can verify that credential through a pluggable, server-side authentication hook, and rejects a dispatch carrying a missing or invalid credential with a distinct, observable signal, separate from routine errors and from transport-level failures.
• This is usable as a standalone authentication option without client certificates (one-way TLS plus a verified token) and as a second factor layered on mutual TLS.
• The identity or claims established by a verified token are available to the authorization layer, so a policy can be expressed over token claims as well as over certificate identity.

Discovery-plane trust

• A worker discovered through any backend is trusted only insofar as it presents a verified identity when connected to; a spoofed or unauthorized advertisement cannot, on its own, cause a routine to be dispatched to an unverified peer.
• The discovery threat model is documented: what each discovery backend does and does not authenticate, and how the identity verification from Support identity-based mutual TLS #249 and Verify mutual TLS peers by SPIFFE workload identity #251 is the trust anchor that contains advertisement spoofing.
• Where a discovery backend can authenticate or sign its advertisements, that protection is available; where it cannot, the verify-identity-on-connect guarantee still holds and is the backstop.

Secure-by-default posture and guardrails

• A worker that binds a non-loopback interface without credentials — a plaintext, off-host-reachable channel — emits a clear warning that its dispatch channel is unauthenticated and reachable beyond the local host.
• A strict mode is available that refuses to start a worker, or to dispatch from a pool, when encryption or an authenticated peer is not in effect, so an insecure configuration fails loudly rather than silently serving an open channel.
• Mutual TLS remains the default whenever credentials are supplied, and none of these changes makes an insecure configuration easier to reach by accident; the safe configuration stays the easy one.

Compatibility (cross-cutting)

• Existing deployments are unaffected: with no authorization policy, no authentication hook, and strict mode disabled, behavior matches today's, aside from the new informational warning when a worker serves plaintext off-host.
• All four behaviors are opt-in and compose with the identity model from Support identity-based mutual TLS #249 and Verify mutual TLS peers by SPIFFE workload identity #251, the existing WorkerPool configuration modes, and the existing discovery backends.