DataStax Enterprise 3.1 Documentation

Configuring and using internal authentication

This documentation corresponds to an earlier product version. Make sure this document corresponds to your version.

Latest DSE documentation | Earlier DSE documentation

Like object permission management that uses internal authorization, internal authentication is based on Cassandra-controlled login accounts and passwords. Internal authentication works for the following clients when you provide a user name and password to start up the client:

Internal authentication stores user names and bcrypt-hashed passwords in the system_auth.credentials table.


The dsetool and Hadoop utilities are not supported by internal authentication.

Configuring internal authentication

To configure Cassandra to use internal authentication, first you make a few changes to the cassandra.yaml. Next, you start up the client using the default user name and password (cassandra/cassandra). Finally, you change the superuser user name and password to secure these credentials, and set up user accounts..

  1. Change the authenticator option in the cassandra.yaml to the native Cassandra PasswordAuthenticator by uncommenting only the PasswordAuthenticator:

    authenticator: org.apache.cassandra.auth.PasswordAuthenticator
  2. Configure the replication strategy for the system_auth keyspace.

  3. Restart DataStax Enterprise. The syntax for starting up the Cassandra client for the first time after configuring internal authentication is:

    <client startup string> -u cassandra -p cassandra
  4. Start cqlsh using the same superuser name and password (cassandra) that you use to start the supported client. For example, to start cqlsh in CQL 3 mode on Linux:

    ./cqlsh -u cassandra -p cassandra

    You can now change the superuser's user name and password.

Changing the default superuser

By default, each installation of Cassandra includes a superuser account named cassandra whose password is also cassandra. A superuser grants initial permissions to access Cassandra data, and subsequently a user may or may not be given the permission to grant/revoke permissions.

To change the superuser account name and password:

  1. Configure internal authentication if you have not already done so.

  2. Create another superuser, not named cassandra.

    Use the CREATE USER command.

  3. Log in as that new superuser.

  4. Change the cassandra user password to something long and incomprehensible, and then forget about it. It won't be used again.

  5. Take away the cassandra user's superuser status.

Now, that the superuser password is secure, set up user accounts and authorize users to access the database objects by using CQL to grant them permissions on those objects.

CQL 3 supports the following statements for setting up user accounts:

Enable internal security in DataStax Enterprise without downtime

The TransitionalAuthenticator and TransitionalAuthorizer allow internal authentication and authorization to be enabled without downtime or modification to client code or configuration.

To implement:

  1. On each node, in the cassandra.yaml file:
    • Set the authenticator to com.datastax.bdp.cassandra.auth.TransitionalAuthenticator.
    • Set the authorizer to com.datastax.bdp.cassandra.auth.TransitionalAuthorizer.
  2. Perform a rolling restart.
  3. Once the restarts are complete, use cqlsh with the default superuser login to setup the users, credentials, and permissions.
  4. Once the setup is complete, edit the cassandra.yaml file again and perform another rolling restart:
    • Change the authenticator to org.apache.cassandra.auth.PasswordAuthenticator.
    • Change the authorizer to org.apache.cassandra.auth.CassandraAuthorizer.
  5. After the restarts have completed, remove the default superuser and create at least one new superuser.

Logging in with cqlsh

To avoid having to pass credentials for every login using cqlsh, in DataStax Enterprise 3.1.3 and later you need to create a cqlshrc file in your ~/.cassandra directory. In earlier releases, you need to name the file .cqlshrc and place it in your home directory. When present, it passes default login information to cqlsh. For example:

username = fred
password = !!bang!!$

Be sure to set the correct permissions and secure this file so that no unauthorized users can gain access to database login information.


Sample cqlshrc files are available in the following directories:

  • Packaged installs: /usr/share/doc/dse-libcassandra
  • Binary installs: <install_location>/resources/cassandra/conf