[
https://issues.apache.org/jira/browse/CASSANDRA-21546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18101331#comment-18101331
]
Stefan Miklosovic edited comment on CASSANDRA-21546 at 8/3/26 11:10 AM:
------------------------------------------------------------------------
The "problem" I have with the current PR here (1) is that there is a new
interface added - \{{IDefaultRoleInitializer}} - okay, but when one looks at
how it is implemented, it is just "glued" together directly into
CassandraRoleManager. What I want to say is that I think it should be done in
such a way that {{IRoleManager}} is somehow already aware of this and an
implementator of a {{IRoleManager}} has to somehow take into account what kind
of {{IDefaultRoleInitializer}} it will work with / accept.
As of now, if somebody has a custom {{IRoleManager}} which is set in
cassandra.yaml and we introduce this feature, then {{IDefaultRoleInitializer}}
will be effectively not used at all until somebody glues it together as it was
done in CassandraRoleManager-alike implementation.
In my opinion it should be done in such a way that custom implementations (or
any implementation for this matter) will naturally integrate this new
capability into their implementations, if I do not look into this ticket and
how {{IDefaultRoleInitializer}} was added I would never know that there is such
a thing I might integrate.
To bring this capability close to IRoleManager, it might be done like this:
{code}
role_manager:
class_name: CassandraRoleManager
parameters:
default_role_initializer_class_name: PasswordDefaultRoleInitializer
default_role_initializer_parameters:
role: cassandra
password: cassandra
{code}
We are already using this technique
{code}
authenticator:
class_name: org.apache.cassandra.auth.MutualTlsAuthenticator
parameters:
validator_class_name: org.apache.cassandra.auth.SpiffeCertificateValidator
{code}
(1) https://github.com/apache/cassandra/pull/4990
was (Author: smiklosovic):
The "problem" I have with the current PR here (1) is that there is a new
interface added - \{{IDefaultRoleInitializer}} - okay, but when one looks at
how it is implemented, it is just "glued" together directly into
CassandraRoleManager. What I want to say is that I think it should be done in
such a way that {{IRoleManager}} is somehow already aware of this and an
implementator of a {{IRoleManager}} has to somehow take into account what kind
of {{IDefaultRoleInitializer}} it will work with / accept.
As of now, if somebody has a custom {{IRoleManager}} which is set in
cassandra.yaml and we introduce this feature, then {{IDefaultRoleInitializer}}
will be effectively not used at all until somebody glues it together as it was
done in CassandraRoleManager-alike implementation.
In my opinion it should be done in such a way that custom implementations (or
any implementation for this matter) will naturally integrate this new
capability into their implementations, if I do not look into this ticket and
how {{IDefaultRoleInitializer}} was added I would never know that there is such
a thing I might integrate.
To bring this capability close to IRoleManager, it might be done like this:
{code}
role_manager:
class_name: CassandraRoleManager
parameters:
default_role_initializer_class_name: PasswordDefaultRoleInitializer
default_role_initializer_parameters:
role: cassandra
password: cassandra
{code}
We are already using this technique
{code}
authenticator:
class_name: org.apache.cassandra.auth.MutualTlsAuthenticator
parameters:
validator_class_name: org.apache.cassandra.auth.SpiffeCertificateValidator
{code}
One possibility how to model this is to have it like
{code}
public class CassandraRoleManager implements IRoleManager,
IDefaultRoleInitializer { ... }
{code}
That way we would be forced to implement the methods in role initializer based
on the configuration settings it got in its {{parameters}}. Nice and clean.
We might go even further and make IRoleManager to extend
IDefaultRoleInitializer (or vice versa) or we might add default methods into
{{IDefaultRoleInitializer}} and override them in {{CassandraRoleManager}} (if
necessary).
So, when I update Cassandra to 7.0 and I have my custom IRoleManager, then I
get the default methods etc. which I can start to use right away in my
implementation so the changes I need to do in order to benefit from this are
minimal.
(1) https://github.com/apache/cassandra/pull/4990
> Support pluggable default role initialization (avoid hardcoded superuser
> password)
> ----------------------------------------------------------------------------------
>
> Key: CASSANDRA-21546
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21546
> Project: Apache Cassandra
> Issue Type: Bug
> Reporter: Aparna Naik
> Assignee: Aparna Naik
> Priority: Normal
>
> Cassandra's first-boot bootstrap hardcodes the creation of a cassandra
> superuser role with a default password (cassandra). Every new cluster starts
> with this guessable credential exposed until an operator manually rotates or
> drops it, and deployments that already use mutual TLS have no way to
> bootstrap a superuser identity without also creating this password-based one.
> This ticket will make the default role bootstrap pluggable via a new
> IDefaultRoleInitializer interface and default_role_initializer config option.
> The existing password-based behavior will be the default implementation for
> backward compatibility, and it will add a MutualTlsDefaultRoleInitializer
> that instead maps a client certificate identity to the superuser role, so no
> password credential needs to exist at all.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
