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