Hi David, could you also implement this when implementing this CEP:
cqlsh -u proxy_svc -p proxy_pass --proxy-execute alice -e 'SELECT * FROM my.app' A new flag - --proxy-execute (or similar) to say what I want that statement to be executed as. We could in theory do something like $ cqlsh -u proxy_svc -p proxy_pass cqlsh> PROXY alice; cqlsh> select * from my.app -- this will be automatically executed as alice PROXY alice - this does not need to be server side or anything like that, it is just that it will add a custom ProxyExecute into the payload when executing queries. On Tue, Aug 4, 2026 at 10:02 PM Jaydeep Chovatia <[email protected]> wrote: > > 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 >>>> >>>> >>> >>> >>
