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č <[email protected]> wrote: > But yes, the statements as you put it will work, of course. > > On Wed, Sep 10, 2025 at 11:33 PM Yifan Cai <[email protected]> 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 < >> [email protected]> 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 < >>> [email protected]> 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č < >>>> [email protected]> 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 < >>>>> [email protected]> 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 <[email protected]> >>>>>> 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č < >>>>>>> [email protected]> >>>>>>> > 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 >>>>>>> > > >>>>>>> > >>>>>>> >>>>>>
