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