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 >>>>>> > > >>>>>> > >>>>>> >>>>>
