Sounds good. Thank you. On Tue, Aug 4, 2026 at 11:59 AM David Capwell <[email protected]> wrote:
> 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]> 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 >>>> >>> >>> >> >> >
