[
https://issues.apache.org/jira/browse/CASSANDRA-21546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18101863#comment-18101863
]
Stefan Miklosovic commented on CASSANDRA-21546:
-----------------------------------------------
Yes, that is given, if we nest then each {{IRoleManager}} is responsible for
the creation of {{IDefaultRoleInitializer}}. If IRoleManager adds a method
{{default IDefaultRoleManager getDefaultRoleManager}} then it is quite
acceptable / expected it will be responsible for its creation.
Currently it is done in such a way that parameters are passed to manager's
constructor. If we had MTLCassandraRoleManager which would extend
CassandraRoleManager then its constructor would need to call {{super(params)}}
and in super's constructor we would create an instance of
{{IDefaultRoleInitializer}} (PasswordDefaultRoleInitializer), which would be
effectively shadowed in sub-class constructor so we might end up with
initializing something which is not needed.
While top-level approach with just consuming the available instance would not
have this "problem".
> 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]
