I have added a section about the endpoint in Sidecar here (1). The working draft for Sidecar is here (2). I would appreciate it if the technical details were not part of this discussion. I am for sure open to the changes in Sidecar implementation but I think they are beyond the practical discussion related to this CEP. I just wanted to provide a working example of what this integration would look like in practice so we do not talk about completely theoretical stuff.
(1) https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-55+Generated+role+names#CEP55Generatedrolenames-Sidecarimplementation (2) https://github.com/apache/cassandra-sidecar/pull/260/files On Sat, Sep 20, 2025 at 7:13 PM Dinesh Joshi <[email protected]> wrote: > This has been a good discussion. I would urge everyone to try and focus on > Stefan’s original proposal. This feature is valuable in Cassandra and will > be good to move forward with it. > > Thanks, > > Dinesh > > On Sat, Sep 20, 2025 at 10:06 AM Štefan Miklošovič <[email protected]> > wrote: > >> Thinking about it more, what you could explore is to make it happen, in >> the most simple way possible, in 4.0 / 4.1, for example. That would be for >> somebody not running Sidecar nor using CEP-55 and they do not expect any >> extensibility nor flexibility around it. >> >> However, I do not know how this approach would be viable in that case. It >> touches more of what Josh has mentioned in his email about initiation of a >> discussion about feature backporting. >> >> On Fri, Sep 19, 2025 at 6:44 PM Venkata Harikrishna Nukala < >> [email protected]> wrote: >> >>> Hi everyone, >>> >>> Following up on my earlier comment, I'd like to elaborate on the >>> UDF-based approach for role generation that I mentioned, as it might offer >>> an interesting alternative perspective to consider alongside CEP-55. >>> >>> I believe we could leverage Cassandra's existing UDF infrastructure to >>> achieve the same goals as CEP-55, with lower implementation complexity. >>> Here's the approach: >>> >>> We could extend the existing CREATE ROLE statement to accept UDF >>> expressions for both role names and passwords: >>> >>> -- Generate role name using UDF >>> CREATE ROLE generate_role_name() WITH PASSWORD = 'static_password'; >>> >>> -- Generate both role name and password >>> CREATE ROLE generate_role_name() WITH PASSWORD = generate_password(16); >>> >>> -- Compose with other functions >>> CREATE ROLE 'service_' + uuid() WITH PASSWORD = secure_random(20); >>> >>> I've actually prototyped this approach and have it working on a branch. >>> It leverages existing UDF features, follows similar patterns to existing >>> CQL statements, and offers operational simplicity (we can just CREATE/DROP >>> functions without updating config/restarts/class path management). I think >>> it's a natural evolution of existing capabilities rather than a new feature >>> category. >>> >>> This isn't meant to replace CEP-55, but rather to offer an alternative >>> implementation path that might achieve the same goals with different >>> trade-offs. If the community prefers CEP-55's explicit CREATE GENERATED >>> ROLE syntax for clarity, that's completely valid. However, if there's >>> interest in exploring a more composable, function-based approach, I'd be >>> happy to share the prototype and discuss further. >>> >>> I appreciate the thorough discussion everyone has had on this topic—it >>> really highlights the thoughtful consideration this community gives to new >>> features. >>> >>> Best regards, >>> Harikrishna >>> >>> >>> On Fri, Sep 19, 2025 at 7:22 PM Josh McKenzie <[email protected]> >>> wrote: >>> >>>> We end up with duplicate implementation >>>> >>>> On further reflection, if we had some kind of shared library the >>>> sidecar and C* could both rely on where we could place CQL-based >>>> operations, we wouldn't have this struggle w/duplication, where we place >>>> functionality, and version-based support. >>>> >>>> Another thing I would *not* suggest we block this CEP on *at all*, but >>>> just an interesting data point IMO. >>>> >>>> On Fri, Sep 19, 2025, at 9:42 AM, Josh McKenzie wrote: >>>> >>>> Wow - I seem to really have struck a nerve. >>>> >>>> Let me reiterate what I closed my earlier email with: Why. Not. Both. >>>> >>>> Nobody is suggesting we gatekeep things and put them only in the >>>> sidecar to try and coerce people to use it. >>>> >>>> Let me reiterate: I strongly disagree with characterizing features >>>> added to the sidecar as: >>>> >>>> Putting this to Sidecar almost guarantees nobody is going to use this >>>> particular functionality. >>>> >>>> That's dismissive, implies that adding features to the sidecar is a >>>> waste of time, and is directly stating that putting things in the sidecar >>>> will "almost guarantee nobody is going to use" it. Which is clearly false >>>> given the multiple large organizations with large cassandra fleets who are >>>> actively integrating the sidecar with their environments today. >>>> >>>> So let's try to back away from the misunderstanding / straw-man that >>>> anyone is suggesting we strategically place features in certain places to >>>> force peoples' hands, and instead stay focused on the discussion at hand. >>>> >>>> We have 3 paths I can see: >>>> >>>> 1. We do it in C* only and expose the API through sidecar as well. >>>> This means either: >>>> 1. It'll be available in trunk only >>>> 2. Or we open Pandora's Box and talk about backporting features >>>> to older GA branches of C* if we want this functionality on all GA >>>> versions >>>> of C* >>>> 2. We do it in the sidecar and add support for each version of C*. >>>> This means: >>>> 1. It'll only be available to people using the sidecar >>>> 3. We do it in both C* and the sidecar. This means: >>>> 1. It'll be available on all GA versions of C* w/out backporting >>>> 2. We *don't* have to tackle the backporting question >>>> 3. We end up with duplicate implementation >>>> >>>> My instinct is we should go with #1: do it in C*, expose the API >>>> through the sidecar, and separately open up a thread of discussion on the >>>> dev list about our backporting policy since it seems like a lot of people >>>> are backporting features to older GA branches anyway. Plus we have some >>>> real hard blockers that are going to slow adoption of new versions of C* >>>> (one-way doors that increase risk), so if we want this functionality >>>> available to users in the near future we'll need to tackle that question. >>>> >>>> I definitely DON'T think we should block this CEP on us having a hard >>>> conversation about backports so: >>>> - feature in C* >>>> - exposed via sidecar >>>> - conversation about backporting separately >>>> >>>> is my preference fwiw. >>>> >>>> On Fri, Sep 19, 2025, at 4:03 AM, Štefan Miklošovič wrote: >>>> >>>> >>>> >>>> On Thu, Sep 18, 2025 at 10:13 PM Johnny Miller < >>>> [email protected]> wrote: >>>> >>>> Hey everyone, >>>> >>>> I wanted to share a few thoughts based on the CEP and this thread. From >>>> my understanding: >>>> >>>> 1 - The Cassandra sidecar uses a standard authentication/authorization >>>> mechanism to connect to Cassandra, just like any other client application, >>>> and is limited to the actions permitted by its certificate/role mapping. >>>> 2 - There’s a proposal for some convenient CQL statements (CREATE >>>> GENERATED ROLE etc,,) that would allow generation of random rolenames >>>> (similar to the existing random password functionality). >>>> 3 - The sidecar would (or could) expose an API for operators to >>>> generate multiple users with random usernames, which would in turn delegate >>>> to this new convenience CQL >>>> 4 - If you don't use sidecar you can still leverage this new CQL via >>>> other processes (Vault, Ansible, Bash whatever) >>>> >>>> I don't understand why sidecar is relevant here. It's just another app >>>> like vault, bash, ansible etc.. using this new CQL which could be reused >>>> for those frameworks also. If it's in CQL then it's going to be reused by >>>> other tech where sidecar is not being deployed. I would like to use this >>>> new CQL as I need to leverage it via what I am able to deploy and sidecar >>>> is not always going to be an option - in fact the vault cassandra plugin >>>> could use this also and is pretty well widely adopted and approved in a lot >>>> of enterprises. >>>> >>>> >>>> See, Josh? Here you have it in black and white. The existence of >>>> something does not guarantee its usage at all. I think we should be >>>> brutally honest here about that. It will take _years_ if any highly >>>> regulated environment e.g. banks etc. will see Sidecar as a viable, vetted >>>> and audited component they might even start to consider to integrate into >>>> their environments. But there are already people on the ground who have to >>>> play the cards they have. I do not think it is reasonable to reject an >>>> in-database solution just for the promise of something different later. It >>>> is not about me not wanting Sidecar to be successful, the very opposite is >>>> true, but we have to be realists first. >>>> >>>> Also, notice how nobody actually protests the addition on CQL level. >>>> "Freezing CQL" is pretty low on the priorities list here. It is nice to >>>> have at best and it is a great goal in the ideal world but when actually >>>> facing it nobody seems to be ultimately against it. >>>> >>>> >>>> >>>> What I’m struggling to understand is where the “sidecar” aspect makes a >>>> difference. If it’s simply acting as a regular application - authenticating >>>> and executing CQL like Ansible, Vault bash scripts, or any other client - >>>> then I don’t see any issue. >>>> >>>> However, if the sidecar is bypassing RBAC or given some special ability >>>> to interact with Cassandra’s DCLs outside of the normal authentication and >>>> authorization flow, that would be a serious concern. It would undermine >>>> both the security model and auditing guarantees. In my view, the sidecar >>>> should behave like any other client with a named user and explicitly >>>> assigned permissions. >>>> >>>> I’m still relatively new to the details of the sidecar project, so if >>>> there is a special non-standard path exposed that allows it to circumvent >>>> existing RBAC and auditing controls, that feels risky and like a potential >>>> security hole. If that’s not the case, and it’s just an app leveraging some >>>> convenience CQL which may help people and I have usually done this with >>>> things like >>>> https://developer.hashicorp.com/vault/docs/secrets/databases/cassandra >>>> - but if theres a conveience CQL that does this better and is also audited >>>> then thats safer no? >>>> >>>> >>>> Yes. Simpler = safer. But to answer your question, I believe the roles >>>> you authenticate with against endpoints are mapped to roles in Cassandra. >>>> Please see this section (1). So there is no custom auth / custom bypassing >>>> etc. It is mapped to Cassandra. >>>> >>>> (1) >>>> https://github.com/apache/cassandra-sidecar/blob/trunk/conf/sidecar.yaml#L217-L279 >>>> >>>> >>>> >>>> Johnny >>>> >>>> On Thu, 18 Sept 2025 at 12:39, Štefan Miklošovič < >>>> [email protected]> wrote: >>>> >>>> This is getting too complex so I have summarized pros / cons for each >>>> approach. Taking Patrick's suggestions into consideration as well so nobody >>>> can tell that I have completely disregarded that. >>>> >>>> >>>> Generation in Sidecar >>>> >>>> - user has to deploy Sidecar >>>> - needs to secure communication channels (TLS) >>>> - calling "create role abc ..." will leak it in audit logs >>>> - there would need to be a pluggable way to configure a generator able >>>> to talk to external services, then additional complexity with patching >>>> Sidecar >>>> - if this is not done then an extra layer of complexity to interpret >>>> the response, putting more stress on integrators >>>> - one Sidecar is enough to be able to create users. We need to >>>> configure just one Sidecar to start to call endpoints capable of user >>>> creation. >>>> - will be available for other Cassandra versions as well >>>> >>>> Generation in Cassandra >>>> >>>> - will be available only in trunk onwards >>>> - custom integrations done by implementing IRoleManager and returning >>>> custom response >>>> - talking via (secure) CQL, no additional plumbing >>>> - nothing leaks in audit logs >>>> - It might be possible to code IRoleManager in such a way that user >>>> credentials would not be stored in Cassandra at all. All operations dealing >>>> with user management might be just proxied to external service (vault etc) >>>> so no credentials whatsoever would be stored in Cassandra. The advantage of >>>> that is that everything would be implemented in one place and CREATE >>>> GENERATED ROLE would be completely transparent from the user's perspective. >>>> This can not be achieved in Sidecar, it can not abstract away what >>>> IRoleManager is doing. >>>> - Cassandra would need to be configured in cassandra.yaml on each node. >>>> While this might seem as sub-optimal, these things are configured just once >>>> and then the creation of next node is for free as the configuration is >>>> taken from some template (same as it would be done for Sidecar anyway). >>>> >>>> In case we wanted to reconfigure Sidecar to talk to another external >>>> service or to reconfigure the generation as such, we would need to take >>>> Sidecar down, change config, and start it up again. In the case of >>>> Cassandra, it is possible to reconfigure this via JMX in runtime so no >>>> restart is necessary. This functionality would be based on Guardrails which >>>> already exposes GuardrailsMBean. I do not think there is a similar >>>> counterpart of this functionality in Sidecar yet. You can not change the >>>> settings on the fly. This would bring additional complexity to Sidecar >>>> which is free in Cassandra already. >>>> >>>> There might be also the fusion of these approaches: >>>> >>>> - Sidecar would expose the endpoint. >>>> - Sidecar would call "CREATE GENERATED ROLE" >>>> - Response would be already returned, processed in Cassandra. >>>> >>>> So from Sidecar's point of view, it would just call an endpoint while >>>> the actual generation would be done in Cassandra. The advantage of that is >>>> that Cassandra might implement a completely custom IRoleManager with all >>>> logic treating role management in a complex way (talking to external >>>> services etc), but by the means of Sidecar it might be integrated further. >>>> >>>> On Thu, Sep 18, 2025 at 10:42 AM Štefan Miklošovič < >>>> [email protected]> wrote: >>>> >>>> By the way, if you do it by Sidecar - that is you generate username on >>>> Sidecar and then you send it via CQL so there will be "create role abc >>>> ...", this will be also visible in audit logs, that exact statement. >>>> However if you do "create generated role" this will not be leaking. If you >>>> want this to be still somehow visible you might consider to turn on >>>> Cassandra's Diagnostic Events on and propagate this information to whatever >>>> sink you want if you truly want that. >>>> >>>> Also, by doing it in Sidecar, you also make Jaydeep's idea about >>>> coding his own CassandraRoleManager which would interpret credentials >>>> stored e.g. in some vault etc. more clunky. >>>> >>>> He would need to touch two things, first he would need to call >>>> Sidecar's endpoint, endpoint would generate credentials, credentials would >>>> be sent to Cassandra, role would be created, Sidecar would need to >>>> interpret these credentials in whatever way Jaydeep sees right. So he would >>>> need to either have _yet another layer of abstraction_ outside of Sidecar >>>> (more work) to interpret what Sidecar returned him, or he would need to >>>> patch Sidecar (more work) and make special generator (more work) which >>>> would know how to talk to whatever external service handling credentials. >>>> Then this service would need to be also somehow configured from Sidecar's >>>> point of view and making it pluggable (more work). >>>> >>>> On Thu, Sep 18, 2025 at 8:08 AM Štefan Miklošovič < >>>> [email protected]> wrote: >>>> >>>> That's right. I also think it is smaller. If you think about it in >>>> purely practical terms, you would need to set up Sidecar, then make the >>>> connection secure via TLS etc. (otherwise username and password would >>>> travel from Sidecar to target recipient of these credentials via >>>> plaintext). Then you need to authenticate the actual caller of that >>>> endpoint so it can reach it in order to call Cassandra to create users for >>>> that ... >>>> >>>> What if you do not want to do ANY OF THESE THNIG? >>>> >>>> I mean ... if somebody is serious about Sidecar, all these things would >>>> be done probably anyway but it is just an unnecessary hurdle to jump over >>>> if one just needs to get the job done. By forcibly siphoning everything >>>> through Sidecar, the very first question of a user would be: why? Why do I >>>> need to take more steps in achieving something? Just to satisfy somebody's >>>> architectural desires? >>>> >>>> Does it make sense to have e.g. CEP about cluster wide restarts in >>>> Sidecar? Yes. Sure. Does it make sense to force people to call Sidecar to >>>> create some users? No. It should be possible to do it with the least amount >>>> of plumbing possible. The use cases are various. >>>> >>>> On Wed, Sep 17, 2025 at 11:03 PM Joel Shepherd <[email protected]> >>>> wrote: >>>> >>>> >>>> >>>> On 9/17/2025 1:21 AM, Štefan Miklošovič wrote: >>>> >>>> On Wed, Sep 17, 2025 at 2:17 AM Joel Shepherd <[email protected]> >>>> wrote: >>>> >>>> Could I make a suggestion? Well, I will make a suggestion :-) , but if >>>> it's not useful then feel free to ignore it. >>>> >>>> Could we talk a bit about how users/operators would work with the >>>> CREATE ROLE features you're proposing? >>>> Somewhat related to that ... is there any need for role "stability" >>>> across clusters: e.g. I want to create a role that can access existing >>>> tables but not create/drop tables or keyspaces, and for my own sanity I >>>> want that role to have the same name on every cluster I operate. Do I have >>>> to implement a custom role name generator to do that, or is that common >>>> enough functionality that it should be supportable by the tooling I'm using >>>> to manage my clusters? >>>> >>>> >>>> >>>> I do not think we have such a requirement for "stability". If you had >>>> this requirement then you would not use the feature we are discussing here >>>> and you created them manually. I also do not think that having the same >>>> name everywhere is a good idea in general. Username is security sensitive >>>> as well. >>>> >>>> We can agree to disagree on this. :-) I generally don't think names >>>> should be considered especially sensitive but am really looking at this >>>> more from how end-users are going to work with the capability. >>>> >>>> The use-case as I understand it is that there are organizations that >>>> have or are going to create large numbers of clusters (say > 3), and they >>>> would appreciate some automation around creating role names and credentials >>>> for all those clusters. The proposal is to extend the CREATE ROLE statement >>>> to enable the database to generate those names and credentials >>>> automatically, including persisting them in the database itself. >>>> >>>> One thing I'm wondering about is what kind of tooling those >>>> organizations are likely to be using for creating/managing all those >>>> clusters. Are they going to be scripting, or are they going to be using >>>> some third-party tooling like Terraform, CloudFormation, Puppet, etc.? If >>>> they're using tooling like that, which is going to be a more natural fit: >>>> making role/password generation available through CQL, or through Sidecar >>>> APIs, or ... ? I don't have an opinion at the moment so that's not a >>>> rhetorical question. I'd actually like to reason through what's going to >>>> work best for the folks who actually have to manage tons of clusters all >>>> day long. >>>> >>>> >>>> >>>> I do not see why we should have a ton of logic / functionality outside >>>> of Cassandra for doing basic things. I think that Cassandra is notoriously >>>> known for its "do it yourself" approach and I think _that_ is the >>>> primary impediment for broader adoption, not if we dare to introduce CREATE >>>> GENERATED ROLE or not. The focus on usability is completely missed. For a >>>> lot of things you want to have you have to have "tooling" which you need to >>>> take care of and so on. People are sick of it. They just want to do the >>>> thing in the most efficient and time-saving manner. >>>> >>>> This isn't an either-or question. I'm not posing "CREATE GENERATED >>>> ROLE" vs infra-as-code (IAC) support. I'm poking at the best way for the >>>> two to work together. Because I think/hope that most people who run large >>>> clusters and/or a lot of clusters (or really a lot of instances of any kind >>>> of service) use some flavor of IAC. There is a lot more than Cassandra to >>>> manage: there's the hosts, disk in some form, networking OS, config, keys, >>>> schema, etc. If I already have a tool to manage all the infra, it'd be nice >>>> for Cassandra to play nicely with that tooling so I can do my basic cluster >>>> setup set-up via automation as well. That doesn't exclude me from putting >>>> down my IAC tool and continuing on to do Cassandra configuration in >>>> Cassandra if I wish ... but in my mind having to jump between tools >>>> (including cqlsh) to configure different aspects of all the things involved >>>> in standing up my cluster is not a usability improvement ... especially if >>>> I have to do it a lot. >>>> >>>> So I'm trying to shed some light on the Sidecar and/or CQL debate by >>>> asking how people are going to be using this functionality "at scale" >>>> (where efficient and time-saving may look very different from adhoc use) >>>> and if there's any benefit to API access via Sidecar vs access via CQL. >>>> >>>> (TBH, I'm actually leaning towards your CQL proposal because I think >>>> the attack surface is actually smaller than it is with letting Sidecar >>>> execute CQL on the API caller's behalf.) >>>> >>>> Thanks -- Joel. >>>> >>>> >>>> >>>> >>>> When I was introduced to this community for the first time, like >>>> 2015-16 maybe, I remember that there was somebody on the mailing list >>>> complaining that "repair should be automatic", "that should be provided", >>>> "this should be natively in". People see this for years. It takes just 9 >>>> years to finally introduce automatic repairs. Thank god for repairing >>>> people finally doing that. They should be weighted in gold. But the >>>> response to that was that "well if you need it you need to write it >>>> yourself, there is no "one size fits all!", you need to take care of that >>>> yourself". Just imagine that. This was a kind of genuinely meant response. >>>> How are we going to make this popular if everything beyond trivial is left >>>> to an end user to figure out. Who sane is going to put up with that? People >>>> just want to turn on the thing and not think too much about it anymore. >>>> >>>> >>>> I don't have strong opinions on CQL vs Sidecar, but I think one way to >>>> frame the debate is to look at which will work best with the tooling that >>>> people already use to manage large numbers of clusters. >>>> >>>> Thanks -- Joel. >>>> On 9/16/2025 3:15 PM, Štefan Miklošovič wrote: >>>> >>>> >>>> Oh crap, what a feedback! If nothing else this shows a lesson to >>>> everybody that the most sure way to have a fast feedback if you are tired >>>> of waiting or impatient so you can move quickly is to just propose your >>>> ideas, then boldly proclaim you go to do something and the universe will >>>> mysteriously take care of finding out somebody who will reject it. Because >>>> people are not always interested in agreeing. A lot of times, they take >>>> action only in case they don't and are put in front of it. So don't be >>>> afraid to take some flak as soon as possible! >>>> >>>> >>>> >>>> On Tue, Sep 16, 2025 at 9:05 PM Patrick McFadin <[email protected]> >>>> wrote: >>>> >>>> Thanks Mick, I'm just digging into this more after a long week of >>>> travel. >>>> Generally, I'm -1 for adding more custom syntax. Another concern of >>>> mine is adding control plane actions in DDL. I understand the usefulness of >>>> a feature like this in ops. It's a great idea.. Here would be my counter >>>> proposal: >>>> - Leave the CQL as is and keep "CREATE ROLE" etc as is, and avoid >>>> making changes to core Cassandra. >>>> >>>> >>>> Why should we keep it "as is"? Genuinely asking. Why? Where is this >>>> need for conserving stuff coming from? Is this what we are doing here? >>>> Adding as little as possible? I think we are stifling innovation >>>> unnecessarily. There was the same discussion about constraints and CHECK >>>> NOT NULL / NOT NULL where we were trying to follow "the Holy >>>> Postgres Grail". I just don't get it. Are we not obsessed with that at this >>>> point? Literally nobody cares if there will be CREATE GENERATED ROLE. >>>> Nobody. Cares. So I do not take this point of yours as valid without some >>>> strong backing from your side. >>>> >>>> >>>> - Move the generation & policy to the sidecar project. A sidecar >>>> endpoint will generate the role name/password, enforce >>>> >>>> prefix/suffix/length requirements, ensure uniqueness, and then return >>>> the role and password (or a secret handle) to the caller. >>>> >>>> >>>> Well the problem I see in putting this to Sidecar is that this would be >>>> only possible to do via HTTP(S). Not everybody is interested in it. Hardly. >>>> Zero interest. Sidecar is 0.2.0 at this point. I think that realistically >>>> speaking I am not far from the truth at all if I say that there is >>>> practically nobody who is using 0.2.0 in production. 0.2.0. I do not count >>>> exceptions as early adopters or Analytics. >>>> >>>> Putting this to Sidecar almost guarantees nobody is going to use this >>>> particular functionality. People have their own control planes, their own >>>> way of generating this stuff and they are not going to deploy Sidecar just >>>> because they want to delegate this task to it. Come on. I think that it >>>> would, paradoxically, create more problems for them. Not less. So again, I >>>> do not take this point as something which is solving anything. This will >>>> have 0 users when put in Sidecar. I think it would be better if we just >>>> flat out refuse this instead of putting that to Sidecar. It is even worse >>>> imho. >>>> >>>> Another problem with Sidecar I see is that the current implementation >>>> is pluggable. How do you want to make this pluggable in Sidecar? Pluggable >>>> how? People might have their own opinion on how role names should be >>>> generated. That is why you can just code your own generator / validator, >>>> put it on the class path and be done with it. How are you supposed to >>>> "patch Sidecar"? You create a custom implementation, then you put it on the >>>> class path of Sidecar? Is this even supported? I think that you have >>>> proposed it with a good will but I don't think that would fly. >>>> >>>> >>>> Why? >>>> - End users will have it faster since it will work with any version of >>>> Cassandra supporting the CREATE syntax. (No having to backport either) >>>> - Keeps control plane actions optional and separated. Not an attack >>>> surface inside core Cassandra >>>> >>>> >>>> Thirdly, what _attack surface_? I think you are pretty aware of the >>>> fact that this feature is by default turned off. If you have an >>>> organisation deploying hundreds of clusters and for each they have to >>>> figure out some role name for a user which is going to use it, how is this >>>> going to be abused concretely? There are dedicated accounts for CQL >>>> management, creation of a role is tied to some workflow etc. What is >>>> attacked exactly and how? Concrete examples please. >>>> >>>> Dineshi had the concern that "what if we just have a script which will >>>> generate roles repeatedly nonstop?" How is this different from having a >>>> script which would generate roles itself instead of Cassandra and it would >>>> execute that? What's the difference really? If you want to abuse it you >>>> will. There is no protection against that unless we put some rate limiting >>>> in front of it - which I do not have a problem to address in follow-up work >>>> as already explained. >>>> >>>> >>>> - We keep the syntax of CQL more generic and less one-off. >>>> >>>> >>>> I don't think this is relevant, really. I think we should abandon this >>>> mindset. At this point, to make the point, I suspect that CQL had to "hurt >>>> you" somehow :) >>>> >>>> Regards >>>> >>>> >>>> - k8s/Cloud native friendly with separation of control plane/data >>>> plane. >>>> Patrick >>>> >>>> >>>> On Tue, Sep 16, 2025 at 7:31 AM Mick <[email protected]> wrote: >>>> >>>> >>>> >>>> >>>> > I think enough time passed for everybody to participate in the >>>> discussion so I would just move on and start the voting thread soon. >>>> >>>> >>>> >>>> Can we give CEP discussions longer than ~one week, please. >>>> >>>> Folk are easily away/offline for a whole week. Take for example many >>>> who were at Community over Code and may still be catching up on their >>>> inbox, thinking dev@ is a less urgent folder. >>>> >>>> I haven't look at how fast the other CEP discuss threads have turned >>>> around, I apologise if I'm only singling one out, my concern applies >>>> generally. >>>> >>>> >>>> >>>>
