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