[VibeSWE]

Problem

Without P_CLUSTER_SECRET (never set in this fork), querier→ingestor syncs forwarded the caller's browser Cookie header whenever the request had no Authorization header. Sessions exist only on the node that issued them, so every user, role, and stream sync made from the UI was rejected by the ingestor with Your session has expired or is no longer valid. The querier only logs that error, so the UI showed success.

Two places did this:

• create_intracluster_auth_headermap, used by the user and role syncs.
• sync_streams_with_ingestors, which copied every caller header.

Reproduction (1 querier + 1 ingestor + MinIO, UI-style cookie login)

Step (via session cookie on the querier)	Before	After
A. Create user → ingest as that user on the ingestor	403	200
B. Remove a user's role → ingest on the ingestor	200 (revoked access still works)	403
C. Delete user → ingest on the ingestor	403 (user never synced)	403
D. Create role, grant it → ingest on the ingestor	403	200
E. Create stream → querier log	sync rejected	no error
Querier "failed to forward request" errors	5	0

For E, ingest still worked before the fix, because ingestors load unknown streams from storage. But stream updates made in the UI never reached live ingestors.

Fix

• User and role syncs (src/utils/mod.rs): with no cluster secret, the caller's Authorization header is forwarded if present. Otherwise the request authenticates as the node with node_token. Cookies are never forwarded. Authenticating as the node grants nothing extra: the querier has already authorized the caller, and every mounted ingestor sync handler reconciles from storage and ignores the request body (Ingestors install the stored role on role sync #78, Ingestors install the stored user on user sync, so role revocations take effect #80).
• Stream sync (src/handlers/http/cluster/mod.rs): sync_streams_with_ingestors drops Cookie. If no other credential remains (Authorization, X-API-KEY, or the cluster secret), it uses the ingestor's node token, but only for default-tenant streams. The node token is root in the default tenant, and the ingestor's stream handler trusts the request's headers and body, so a tenant's stream would land in the default tenant. A tenant's stream sync without a credential now fails and is logged, asking for P_CLUSTER_SECRET. A node token that can't be encoded fails only that node's sync.
• Prism stats (src/storage/field_stats.rs): without a cluster secret, the dataset-stats path forwards only the caller's Authorization header and otherwise returns an error asking for P_CLUSTER_SECRET. Falling back to the querier's root token there would skip the querier's per-dataset checks for the caller. Prism mode is disabled at startup in this fork, so this path is unreachable today; it now fails closed if Prism is ever turned on.
• Tests: unit tests cover the header selection in all three places. Main's test that asserted cookies are copied now asserts the opposite.

Known limitation

In multi-tenant mode without a cluster secret, the node-token fallback runs as root in the default tenant. Tenant-scoped syncs (user delete, role add/remove, password reset) then reconcile the same user ID in the default tenant, which is effectively a no-op. The tenant's change still doesn't reach ingestors, which is no worse than before, when the sync was rejected outright. This now applies to UI (cookie) callers too, not only callers with no credentials. Distributed multi-tenancy needs P_CLUSTER_SECRET anyway (see otel_generator.rs and traces.rs).

🤖 Generated with Claude Code