Thank you guys for the feedback! Really appreciate it. There is a lot to go
through, I ll start with Jaydeep:
This is indeed an interesting suggestion. I think this is definitely
possible to add. The default output is into CQL response so that is the
reason you see it in CQL shell output. My idea behind this was that if this
is executed programmatically by some "roles management application", it
will talk CQL, so credentials will be sent to it and the CQL connection is
presumably encrypted. So there is basically no way to "leak this". The
result in shell is just for the demo purposes or for operators for which it
is just enough to copy it over somewhere. It is nowhere to be found in
logs. Only commands are in .cassandra/cqlsh_history so ...
Anyway, the answer is that yes, we can just add an interface, configured in
cassandra.yaml, (ParameterizedClass etc), when default sink would be CQL
response. If something else is specified, credentials would be put there
and it would return in CQL view whatever that extension would return as you
showed. Easy.
Francisco:
I think that might be done via
CREATE GENERATED USER WITH GENERATED PASSWORD AND OPTIONS = {'suffix':
'read_only'}
I see that this is supported in (1). I am not completely sure it is
supported in vanilla Cassandra. There was a ticket about this here (2)
where it was suggested and we were working on it but there was quite a
backlash against this because guys said that "well there is no need for
this, nobody is using it". I think we can finish it now and support OPTIONS
as well so this feature can use that.
We could also go without CASSANDRA-20000 but you would need to implement
your own custom CassandraRoleManager just to support this because that does
not and I consider that pretty weird if you ask me. We should not be forced
to use a custom role manager just for this thing to function properly, if
it is going to be inherently part of the code base.
Dinesh:
rate limits ... yes, useful, but I think this is out of scope for now. I
think this should be handled way more robustly, not only rate limiting
this, but also rate limiting e.g. the login attempts and so on to prevent
attacks etc. I am afraid that we would be doing something half-baked here.
I really think this might be done on top of all these changes in a separate
CEP.
Alex Petrov was also looking into unified rate limiting, I can not find the
thread right now ... I was asking how authentication requests are going to
be affected by that and is the model about that ... Anyway, I think this
should not be part of that for now.
(1)
https://docs.datastax.com/en/cql-oss/3.x/cql/cql_reference/cqlCreateRole.html
(2) https://issues.apache.org/jira/browse/CASSANDRA-20000
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
>> > >
>> >
>>
>
