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 dse_auth.credentials column family.
The dsetool and Hadoop utilities are not supported by internal authentication.
To configure Cassandra to use internal authentication, first you change the superuser password, and then you make a few changes to the cassandra.yaml as described in this procedure. To use authentication, you start up the client using the default user name and password (cassandra/cassandra).
Change the authenticator option in the cassandra.yaml to PasswordAuthenticator by uncommenting only the PasswordAuthenticator:
#authentication backend, implementing IAuthenticator; used to identify users #authenticator: org.apache.cassandra.auth.AllowAllAuthenticator authenticator: com.datastax.bdp.cassandra.auth.PasswordAuthenticator #authenticator: com.datastax.bdp.cassandra.auth.KerberosAuthenticator
Restart DataStax Enterprise. The syntax for starting up the Cassandra client for the first time after configuring native authentication is:
<client startup string> -u cassandra -p cassandra
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 -3 -u cassandra -p cassandra
You can now change the superuser's user name and password.
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:
Configure internal authentication if you have not already done so.
Create another superuser, not named cassandra.
Use the CREATE USER command.
You can now set up user accounts and authorize users to access the database objects by using CQL to grant them permissions on those objects.
Log in as that new superuser.
Change the cassandra user password to something long and incomprehensible, and then forget about it. It won't be used again.
Take away the cassandra user's superuser status.
CQL 3 supports the following authentication statements, which are described in the CQL alphabetical security command reference:
The TransitionalAuthenticator and TransitionalAuthorizer allow internal authentication and authorization to be enabled without downtime or modification to client code or configuration.
To avoid having to pass credentials for every login using cqlsh, you can create a .cqlshrc file your home directory. When present, it passes default login information to cqlsh. For example:
[authentication] 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: