[
https://issues.apache.org/jira/browse/CASSANDRA-21546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18101851#comment-18101851
]
Stefan Miklosovic commented on CASSANDRA-21546:
-----------------------------------------------
I do not see {{IDefaultRoleInitializer}} to be fit as a standalone / top-level
config because it would be unusable without {{IRoleManager}} which calls it. If
there was no {{IRoleManager}}, then {{IDefaultRoleInitializer}} would be
executed in what context exactly? Since there is direct relationship between
the existence of {{IDefaultRoleInitializer}} and {{IRoleManager}} then I see it
to be completely fine to embed it like that. Basically, on the config level we
are trying to have it top-level but it is always embedded in {{IRoleManger}}
and can't live without it.
Yes, ParameterizedClass can take only Map<String, String> so the prefixing you
see is rather the result of this restriction.
While I was dealing with that code I was asking myself every now and then ...
why are we even trying to add an interface like that? Why is this not on
{{IRoleManager}} directly, actually? Why could not be role manager itself
responsible for the default role creation? Right ... because you want to have
it pluggable, even we are based on CassandraRoleManager, once we want it on
passwords, another time on MTLS.
But ... is not IRoleManager _pluggable already_? If we collapsed this interface
into {{IRoleManager}} then you would need to have
"PasswordCassandraRoleManager" and then "MTLSCassandraRoleManager" and there
you would take parameters as Map<String, String>. In both cases you would take
the parameters as we are used to without any prefixing.
If we had a manager per the way it creates default roles, we might say that
{{CassandraRoleManager}} will react to role / password combo and
{{MTLSCassandraRoleManager}} would extend {{CassandraRoleManager}} and it would
override the way it creates default roles accordingly.
> 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]
