Stefan, I asked AI to review this request and the answer was that it shouldn’t be too bad to do and most of the work is adding “PROXY Alice;” support. Says that since we reuse the DSE key that its already backed into the client so not a lot… will see when I actually get there =)
> On Aug 5, 2026, at 6:27 AM, Štefan Miklošovič <[email protected]> wrote: > > 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 >>>>> >>>>> >>>> >>>> >>>
