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]> 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]> 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]> > 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]> 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]> >> 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]> >> 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 >>> >> >> > >
