2 Commits

Author	SHA1	Message	Date
Joseph Doherty	228ff8b428	fix(grpc): one public constructor on ControlPlaneAuthInterceptor — two made the gate inert ... Caught by the Phase 0 live gate, not by the suite. Grpc.AspNetCore registers the interceptor BY TYPE, and InterceptorRegistration.GetFactory() throws "Multiple constructors accepting all given argument types have been found" when more than one public constructor is applicable. The interceptor had two: the DI one and a prefix-set overload added for later phases. The failure mode is nasty. The throw happens inside the interceptor pipeline on every call, so nothing fails at startup — the site node boots, joins, reports healthy. Every gated call then dies with Unknown / "Exception was thrown by handler", which reads as a handler bug rather than an auth bug. And it fails OPEN in the sense that matters least and closed in the sense that matters most: no call is ever authorized, but no call is ever correctly REFUSED either, so the rig showed identical errors for a correct key, a wrong key and no key at all. Live evidence, site-a: three PullAuditEvents calls, three identical InvalidOperationExceptions in the node log. Fix: the prefix-set constructor is internal (Host.Tests already has InternalsVisibleTo). Later phases extend DefaultGatedPrefixes rather than adding a second public registration shape. Why the tests missed it, and what changed: ControlPlaneAuthEndToEndTests registered the interceptor with AddSingleton alongside AddGrpc, so DI handed back the instance and Grpc.AspNetCore's activation path — the thing that throws — never ran. The harness now registers exactly as Program.cs does, by type and not in DI. Plus a direct reflection assertion that the type has exactly one public constructor, since that is the real invariant and it is cheap to pin.	2026-07-22 17:56:51 -04:00
Joseph Doherty	2ee84af1c0	feat(grpc): PSK-authenticate the site gRPC control plane; drop the vestigial management receptionist registration ... Phase 0 of the ClusterClient→gRPC migration (docs/plans/2026-07-22-clusterclient-to-grpc-plan.md). Standalone hardening: it closes a gap that exists today and is a precondition for moving command/control onto gRPC in later phases. T0.1 — delete the ManagementActor ClusterClientReceptionist registration. It was built for an out-of-cluster CLI that was never written: the shipped CLI speaks HTTP Basic to /management, which asks the actor in-process through ManagementActorHolder. Nothing in the repo ever sent to /user/management. The actor still runs there; only the cross-boundary advertisement is gone. Six documents claimed the CLI used ClusterClient — including the CLI's own README "Architecture Notes" — and are corrected here rather than left to rot. T0.2 — record, do not port, the dead integration-routing path. IntegrationCallRequest is unwired at BOTH ends: RouteIntegrationCallAsync has zero callers anywhere, and RegisterLocalHandler(Integration, …) appears only in a test, so production always answers "Integration handler not available". It is excluded from the gRPC contract (28 of 29 commands migrate) rather than enshrined on an additive-only wire format, and deleting it during a transport migration would mix a behavioural change into a change whose whole value is that behaviour is identical. See docs/known-issues/2026-07-22-integration-call-routing-is-dead-code.md. T0.3 — preshared-key authentication on SiteStreamService. The service shipped with no auth at all: plaintext h2c, no interceptor, so anything that could reach a site node's :8083 could open a live data stream or read audit rows back via PullAuditEvents/PullSiteCalls. ControlPlaneAuthInterceptor now gates /sitestream.SiteStreamService/ — modeled on LocalDbSyncAuthInterceptor (constant-time compare, fail-closed, PermissionDenied) but gating a SET of service prefixes so phases 1A/1B add services rather than interceptors. LocalDb sync keeps its own separate key: it authenticates the pair partner, not central, and collapsing the two would make a site's central-facing key also admit writes into its database. Keys are per site (SB-GRPC-PSK-<siteId>), never fleet-wide, so a compromised site yields only its own. Central attaches them through ControlPlaneCredentials, which binds CallCredentials to the channel — covering unary and streaming uniformly, and letting the key resolve asynchronously, which a client interceptor could not do without blocking. All three central→site channel creation sites go through it (SiteStreamGrpcClient and both audit pull invokers); the pull invokers' channel caches are re-keyed by (site, endpoint) because credentials are per-site and bound to the channel. Two decisions beyond the plan: * StartupValidator now requires GrpcPsk on Site nodes. The plan specified only the runtime gate, but fail-closed with no boot check produces a node that joins, answers heartbeats and reports healthy while refusing every stream, audit pull and telemetry ingest — silent and total. Same reasoning as the existing inbound API-key pepper rule. * Added Communication:SitePsks as a central-side key map. The plan assumed central would read the store, seeded via a dev KEK; the docker rig deliberately boots with no master key, so store-only resolution would leave it unable to dial its own sites. The store stays primary — it is the only source that can serve a site added at runtime — with the map covering key-less hosts and one-off pins. Neither source falling back to "unauthenticated" is the invariant. T0.4 — dev keys on both rigs and tests. 34 tests. The seven that matter most exercise a real in-process gRPC stack over TestServer: the unit tests on either side of the wire would both stay green if the halves disagreed, and gRPC refuses call credentials on a plaintext channel by default — the UnsafeUseInsecureChannelCallCredentials opt-in is only provable by making a real call. They confirm correct key passes on unary AND streaming, wrong key and no-credentials both get PermissionDenied, and an unresolvable key fails the call with nothing reaching the service. OPERATIONAL: a site node upgraded to this build without a key will not boot. That includes the gitignored deploy/wonder-app-vd03/ overlay.	2026-07-22 17:51:09 -04:00