You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stefan Miklosovic (Jira)" <ji...@apache.org> on 2026/08/03 09:51:00 UTC
[jira] [Comment Edited] (CASSANDRA-21546) Support pluggable default role initialization (avoid hardcoded superuser password)

    [ 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 9:50 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 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 in 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 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

> 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org