Hi all, I'd like to start a discussion on PIP-488, which adds a pluggable hook for authentication audit events.
PR: https://github.com/apache/pulsar/pull/26144 Problem ------- Today the only per-authentication signal in Pulsar is AuthenticationMetrics - aggregate success/failure counters by provider and error code. There is no way to get a structured, per-login record: "principal P authenticated via method M from address A at time T," or "a failed attempt with reason R came from A." Security teams need that for SIEM ingestion, anomaly detection (failure spikes from one source, a principal showing up from an unexpected place), forensics, and compliance. Counters can't answer "who, from where, when, and why did this fail." Right now operators have to scrape provider logs (unstructured, mostly absent) or fork the broker. Proposal -------- Add a small, optional hook that emits a structured, secret-free AuthenticationEvent (type, method, principal, remote address, transport, timestamp, and on failure a reason/code - never any credentials) on login success, failure, and refresh, on both the binary and HTTP/HTTPS paths. Events are handed off through a bounded background queue, so a slow or throwing listener can never stall or fail authentication; on overflow, events are dropped and counted. With nothing configured, the feature is off and costs nothing. Open question for the thread ---------------------------- I looked at BrokerInterceptor, which is the closest existing extension point. It doesn't cover this today: it only fires on successful binary connections (onConnectionCreated), runs inline on the event-loop thread (can block auth), isn't authentication-scoped, and can't be reached from pulsar-broker-common where HTTP/admin auth happens. So the PIP presents two ways to close the gap: - Option A: add a default onAuthenticationEvent(...) method to the existing BrokerInterceptor and reuse its loading/lifecycle. Avoids a second plugin; the trade-off is that these callbacks are dispatched off-thread while the rest of BrokerInterceptor stays inline. - Option B: a dedicated AuthenticationEventListener SPI in pulsar-broker-common. Cleaner separation and a natural HTTP emission point, at the cost of one more plugin interface and config setting. I'd especially like feedback on the A-vs-B choice, plus the event fields, the non-blocking / drop-on-overflow behavior, and the proposed metrics. Full details are in the PR. Thanks for taking a look. Best regards, Pavel Zeger
