Added the following to the CEP "To maintain operational visibility the connection based metrics should have a faked connection per client; this makes sure existing client visibility still works when the client was actually proxied"
> On Aug 1, 2026, at 9:20 PM, Jaydeep Chovatia <[email protected]> > wrote: > > Yeah, David. It makes sense. Basically, some sort of way to track proxied > users for the last N minutes and then include them in the original metrics. > > Jaydeep > > On Thu, Jul 30, 2026 at 3:17 PM David Capwell <[email protected] > <mailto:[email protected]>> wrote: >> Looked into it, and this is what I see >> >> - ConnectedNativeClientsByUser JMX gauge >> - system_views.clients.username >> - nodetool clientstats >> >> These are all connection based metrics and not user metrics. With the model >> that the request is what defines the user you can’t “fix” these metrics as >> they act as counters over connections. >> >> All other places would show the user U1, its just these places that would >> only show P1. >> >> What we could do is create “fake” connections that are only a metrics >> concern. Right now we do >> >> if (server != null) >> clients.addAll(server.getConnectedClients()); >> >> So we could do something like this after the server check >> >> if (proxyServer != null) >> clients.addAll(proxyServer.getConnectedClients()); >> >> And this just lies and says every client seen in the last N minutes >> (assuming we want to expire) has 1 connection (return ConnectedClient; >> though likely need to refactor). The only thing that this buys us is that >> we see the “userName” and “requestCount”, “authenticationMode” (proxied). >> >> So we know what clients touched the cluster and how many requests they made >> >> Jaydeep does this make sense to you? >> >> >>> On Jul 29, 2026, at 11:07 AM, David Capwell <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Good feedback, ill look into the complexity and get back to this. >>> >>>> On Jul 28, 2026, at 2:35 PM, Jaydeep Chovatia <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >This means all the client metrics will be showing P1 and not U1 >>>> Should we make it configurable, since some users may prefer the actual >>>> user instead of the proxy for better debugging purposes? >>>> >>>> Jaydeep >>>> >>>> On Mon, Jul 27, 2026 at 3:40 PM David Capwell <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>> Thanks for taking a look! >>>>> >>>>>> Today, one TCP connection → one ClientState → one AuthenticatedUser for >>>>>> the connection's lifetime, shared across all concurrently in-flight >>>>>> requests (multiplexed by stream ID). With the proposal, a single >>>>>> connection can carry concurrent requests for different target >>>>>> identities. Is the target identity resolved per-request without ever >>>>>> mutating the shared ClientState, or could two concurrent requests race >>>>>> and cross-contaminate each other's effective identity? >>>>> >>>>> >>>>> Very good question! The TCP user will be the proxy user (say P1). We >>>>> detect that the request is for user U1 and then do something like this >>>>> >>>>> QueryState qstate = connection.validateNewMessage(request.type, >>>>> connection.getVersion()); >>>>> if (isProxyRequest(request)) { >>>>> var proxiedUser = extractProxiedUser(request); >>>>> var rejection = validateProxyAllowed(qstate, request, >>>>> proxiedUser); >>>>> if (rejection != null) return rejection; >>>>> qstate = qstate.proxied(proxiedUser); // This request >>>>> switched away from P1 to U1 (proxied by P1) >>>>> } >>>>> >>>>> Message.logger.trace("Received: {}, v={}", request, >>>>> connection.getVersion()); >>>>> connection.requests.inc(); >>>>> Message.Response response = request.execute(qstate, requestTime); >>>>> >>>>> This means all the client metrics will be showing P1 and not U1; these >>>>> are the only places that reach into the connection’s user, the rest of >>>>> the code passes around QueryState or ClientState >>>>> >>>>>> On Jul 24, 2026, at 6:48 PM, Jaydeep Chovatia >>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>> >>>>>> Overall, the proposal looks good. I have the following >>>>>> implementation-related question: >>>>>> Today, one TCP connection → one ClientState → one AuthenticatedUser for >>>>>> the connection's lifetime, shared across all concurrently in-flight >>>>>> requests (multiplexed by stream ID). With the proposal, a single >>>>>> connection can carry concurrent requests for different target >>>>>> identities. Is the target identity resolved per-request without ever >>>>>> mutating the shared ClientState, or could two concurrent requests race >>>>>> and cross-contaminate each other's effective identity? >>>>>> >>>>>> Jaydeep >>>>>> >>>>>> On Fri, Jul 24, 2026 at 2:38 PM David Capwell <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>>> Hi everyone, >>>>>>> >>>>>>> We'd like to propose CEP-64: Proxy Execution Support [1] for adoption >>>>>>> by the community. This feature adds a new PROXY permission to >>>>>>> Cassandra which allows operators to give permission to impersonate >>>>>>> different users. >>>>>>> >>>>>>> Proxy architectures are now a standard part of modern Cassandra >>>>>>> deployments, yet today they force operators into an unacceptable >>>>>>> choice: forward raw end-user credentials (creating leakage risk and >>>>>>> breaking with mTLS/SSO), or collapse everyone into a single service >>>>>>> account (losing per-user authorization and meaningful audit trails). >>>>>>> Neither option supports production requirements for both a proxy layer >>>>>>> and genuine per-user access control. >>>>>>> >>>>>>> This CEP closes that gap by letting a trusted proxy role execute >>>>>>> requests on behalf of specific end-users, with Cassandra enforcing the >>>>>>> target user's permissions and recording both the proxy and >>>>>>> effective-user identities. The result is the operational benefits of >>>>>>> proxies — simplified connectivity, topology hiding, transparent >>>>>>> migrations — without sacrificing security or auditability. >>>>>>> >>>>>>> The CEP is linked here: >>>>>>> https://cwiki.apache.org/confluence/spaces/CASSANDRA/pages/440305049/CEP-64+Proxy+Execution+Support >>>>>>> >>>>>>> Looking forward to the discussion of this CEP here on the dev list. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> [1] >>>>>>> https://cwiki.apache.org/confluence/spaces/CASSANDRA/pages/440305049/CEP-64+Proxy+Execution+Support >>>>> >>> >>
