Hi Yifan, current implementation will return only the generated password for the first case and role name for the second. It will return only what is generated. If you use "create generated user with generated password" it will return both. I think that behaviour makes sense. Why do you want to return a role and password when you already know what it is?
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 >>>>>> > > >>>>>> > >>>>>> >>>>>
