Thank you everybody for the participation. TLDR from this thread:
- rate limiting is out of scope, indeed valuable but should be treated more robustly outside this CEP - CREATE GENERATED ROLE WITH password = '123' as well as CREATE ROLE abc WITH GENERATED PASSWORD will for sure work - an operator will be able to specify prefix and / or suffix to generated role name in case of default UUIDRoleNameGenerator. It will be also possible to specify length of randomly generated role name string - It will be possible to return custom response in CQL in case integrators will need to represent the response differently I think enough time passed for everybody to participate in the discussion so I would just move on and start the voting thread soon. Regards On Wed, Sep 10, 2025 at 11:57 PM Yifan Cai <yc25c...@gmail.com> wrote: > Thanks for confirming. > > The tabular output is copy-pasted from the CEP and only for illustration. > There is no need to print the information that is already known. > > - Yifan > > On Wed, Sep 10, 2025 at 2:40 PM Štefan Miklošovič <smikloso...@apache.org> > wrote: > >> But yes, the statements as you put it will work, of course. >> >> On Wed, Sep 10, 2025 at 11:33 PM Yifan Cai <yc25c...@gmail.com> wrote: >> >>> CEP looks good and the feature is useful for automation. >>> >>> Just a quick question, will the following two DCL statements work? >>> >>> CREATE ROLE my_role WITH GENERATED PASSWORD; >>> generated_password | role_name >>> --------------------+---------------------------------- >>> 0zdHJ,]dW[s6 | my_role >>> >>> CREATE GENERATED ROLE WITH PASSWORD = '42'; >>> generated_password | role_name >>> --------------------+---------------------------------- >>> 42 | cbaeea62551d41dbb26a349428ccd741 >>> >>> - Yifan >>> >>> On Wed, Sep 10, 2025 at 11:21 AM Venkata Harikrishna Nukala < >>> n.v.harikrishna.apa...@gmail.com> wrote: >>> >>>> Thanks for the CEP! I think it is a good idea. Wondering if user >>>> defined functions can be leveraged here. A user can define a function that >>>> returns a role name. If create role statement can call this function, then >>>> get the role name and create a role with it. This way operators can create >>>> and pick up any role name generation function to get the role names. These >>>> functions can accept multiple arguments if required (based on complexity of >>>> requirement/business logic). Probably we can leverage UDFs for passwords as >>>> well. >>>> >>>> On Wed, Sep 10, 2025 at 6:04 AM Jaydeep Chovatia < >>>> chovatia.jayd...@gmail.com> wrote: >>>> >>>>> >What I suggest instead is to add default methods to IRoleManager, >>>>> telling how the response in CQL should look like when a password / >>>>> username >>>>> is generated. The default implementation would return a response >>>>> containing >>>>> generated password / user name if any and it would return null if this >>>>> feature is not used. >>>>> Yeah, default methods would do. By default, it would show response on >>>>> console, and one can configure it to show *null *(if not used) or >>>>> implement their own version and return vault path, etc. >>>>> >>>>> Jaydeep >>>>> >>>>> On Tue, Sep 9, 2025 at 9:18 AM Štefan Miklošovič < >>>>> smikloso...@apache.org> wrote: >>>>> >>>>>> Hi Jaydeep, >>>>>> >>>>>> I was trying to model what you have described and I do not think it >>>>>> is a good approach. First of all, if you have a secret sink, you have to >>>>>> have a secret source. If you save something to e.g. vault, then you also >>>>>> need to read it back so you can provide the credential / password upon >>>>>> login attempts to compare with hashed password from cqlsh. >>>>>> >>>>>> But this whole concept of sinks / sources is already done. Sink is >>>>>> our CassandraRoleManager / IRoleManager which has e.g. "createRole" >>>>>> method >>>>>> (among others). Source is PasswordAuthenticator / IAuthenticator, which >>>>>> reads a password from a table. >>>>>> >>>>>> So what you want to do, like custom sinks, is doable when you >>>>>> implement your own IRoleManager and IAuthenticator where implementations >>>>>> would talk to your target environment. It is completely transparent from >>>>>> Cassandra's point of view. You can then delegate this already as this >>>>>> functionality is already pluggable. >>>>>> >>>>>> Your concern about showing credentials in CQL response is something >>>>>> which is happening on a different level. >>>>>> >>>>>> What I suggest instead is to add default methods to IRoleManager, >>>>>> telling how the response in CQL should look like when a password / >>>>>> username >>>>>> is generated. The default implementation would return a response >>>>>> containing >>>>>> generated password / user name if any and it would return null if this >>>>>> feature is not used. >>>>>> >>>>>> Then, in your custom IRoleManager talking to a vault, you would >>>>>> create the role however you please and you would return from that method >>>>>> what you want CQL response to a user to look like. >>>>>> >>>>>> Basically, the abstraction of sinks is unnecessary in this situation. >>>>>> >>>>>> Regards >>>>>> >>>>>> On Tue, Sep 9, 2025 at 3:36 AM Jaydeep Chovatia < >>>>>> chovatia.jayd...@gmail.com> wrote: >>>>>> >>>>>>> First off, I want to say that the current scope of CEP-55 is a >>>>>>> really good start. The proposal to support generated role/user names >>>>>>> (building on CEP-24) addresses real security and operational pain >>>>>>> points, >>>>>>> and I think this addition will be very useful to operators at scale. >>>>>>> >>>>>>> One thought I had: do you think we could extend this CEP a little >>>>>>> further to improve secret handling? >>>>>>> >>>>>>> At the moment, generated passwords are returned directly to the >>>>>>> client/console. While this works, it also means operators must take care >>>>>>> not to leak these values into logs, CI/CD pipelines, or audit trails. In >>>>>>> security-sensitive deployments, this is often a blocker. >>>>>>> >>>>>>> *Suggestion:* >>>>>>> Introduce a concept of a *“Secret Sink”* for generated credentials: >>>>>>> >>>>>>> - >>>>>>> >>>>>>> *Default sink:* Cassandra’s existing system_auth tables (current >>>>>>> behavior, fully backward compatible). >>>>>>> - >>>>>>> >>>>>>> *Pluggable extension:* Operators can configure a SecretSink >>>>>>> implementation >>>>>>> that writes secrets directly into a vault of their choice (e.g., >>>>>>> HashiCorp >>>>>>> Vault, AWS Secrets Manager, GCP Secret Manager). >>>>>>> - >>>>>>> >>>>>>> *Client view:* Instead of receiving the plaintext password, the >>>>>>> client would receive a reference/handle (e.g., >>>>>>> vault://kv/cass/prod/roles/abc123) that applications can resolve >>>>>>> via their secret manager. >>>>>>> >>>>>>> This way, operators who are fine with today’s behavior can keep it, >>>>>>> while those with stricter requirements can enable secret redaction and >>>>>>> externalized storage. >>>>>>> >>>>>>> Do folks think it makes sense to consider this as part of CEP-55, or >>>>>>> perhaps as a follow-up CEP once the base functionality is in place? >>>>>>> >>>>>>> Jaydeep >>>>>>> >>>>>>> On Mon, Sep 8, 2025 at 2:28 PM Francisco Guerrero < >>>>>>> fran...@apache.org> wrote: >>>>>>> >>>>>>>> Hi Stefan, >>>>>>>> >>>>>>>> Thanks for bringing this CEP for discussion. I think it's a good >>>>>>>> feature, but >>>>>>>> I would like to have the ability to define some suffix or prefix to >>>>>>>> the name of >>>>>>>> the role. Thinking from an operator point of view, this would help >>>>>>>> to visually >>>>>>>> identify the type of role we are generating. Let's say you have a >>>>>>>> role that is >>>>>>>> allowed to read and write data to the cluster, then I'd like to >>>>>>>> either prefix or >>>>>>>> suffix the role name with _read_write. And if I have a read only >>>>>>>> user, I'd like >>>>>>>> to do the same with the _read_only suffix. I haven't really thought >>>>>>>> through >>>>>>>> about what the grammar would look like if we were to support >>>>>>>> prefixes/suffixes, but this is one idea: >>>>>>>> >>>>>>>> cassandra@cqlsh> CREATE GENERATED ROLE WITH SUFFIX _read_only; >>>>>>>> >>>>>>>> generated_role_name >>>>>>>> ---------------------------------------- >>>>>>>> b97ef7fcfd_read_only >>>>>>>> >>>>>>>> I think this makes the role name less cryptic and more operator >>>>>>>> friendly. >>>>>>>> >>>>>>>> Let me know your thoughts on this. >>>>>>>> >>>>>>>> Best, >>>>>>>> - Francisco >>>>>>>> >>>>>>>> On 2025/09/08 20:14:26 Dinesh Joshi wrote: >>>>>>>> > This is a great feature to have Stefan. Like you already pointed, >>>>>>>> it pairs >>>>>>>> > really well with CEP-24. I am only concerned about scripts going >>>>>>>> crazy and >>>>>>>> > generating way too many accounts. Do you have any plans for >>>>>>>> throttling or >>>>>>>> > placing a limit on the number of auto-generated accounts that >>>>>>>> could be >>>>>>>> > created by an admin? >>>>>>>> > >>>>>>>> > It would be nice if these accounts could be TTL'd after a set >>>>>>>> period of >>>>>>>> > time of inactivity. I'm thinking from a testing standpoint where >>>>>>>> you want >>>>>>>> > to create a fresh account and not worry about cleaning up because >>>>>>>> Cassandra >>>>>>>> > could TTL it automatically. I recognize this will expand the >>>>>>>> scope of your >>>>>>>> > CEP and I'll be happy to work on contributing to it. >>>>>>>> Alternatively, if you >>>>>>>> > think it might be better to have this as a separate CEP that's ok >>>>>>>> too. >>>>>>>> > >>>>>>>> > Thanks, >>>>>>>> > >>>>>>>> > Dinesh >>>>>>>> > >>>>>>>> > On Mon, Sep 8, 2025 at 6:35 AM Štefan Miklošovič < >>>>>>>> smikloso...@apache.org> >>>>>>>> > wrote: >>>>>>>> > >>>>>>>> > > Hi list, >>>>>>>> > > >>>>>>>> > > I would like to propose CEP-55. It is about the ability to >>>>>>>> create users / >>>>>>>> > > roles without specifying names ourselves. >>>>>>>> > > >>>>>>>> > > This is a very handy feature for systems where we want to have >>>>>>>> a way for >>>>>>>> > > the system to generate user names / role names for us by some >>>>>>>> predefined >>>>>>>> > > manner. If there is a company deploying clusters in some >>>>>>>> automated manner / >>>>>>>> > > on demand, the creation of user names / roles is left to an >>>>>>>> operator to >>>>>>>> > > figure out. This task can be delegated to cluster and user name >>>>>>>> / role name >>>>>>>> > > would be returned as part of CQL response. >>>>>>>> > > >>>>>>>> > > This feature might be also used e.g. for demo / evaluation >>>>>>>> purposes, for >>>>>>>> > > creation of technical users where role names do not matter, or >>>>>>>> for >>>>>>>> > > increased security where role names would not be leaked in logs. >>>>>>>> > > >>>>>>>> > > This is quite a powerful technique, especially with CEP-24 / >>>>>>>> password >>>>>>>> > > generation, where an operator just has to execute: >>>>>>>> > > >>>>>>>> > > CREATE GENERATED USER WITH GENERATED PASSWORD; >>>>>>>> > > >>>>>>>> > > and both (valid) name and password would be returned. >>>>>>>> > > >>>>>>>> > > (1) >>>>>>>> > > >>>>>>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-55+Generated+role+names >>>>>>>> > > >>>>>>>> > >>>>>>>> >>>>>>>
