Configuring and using internal authentication

Internal authentication is based on Cassandra-controlled login accounts and passwords.

Like object permission management (which uses internal authorization), internal authentication is based on Cassandra-controlled login accounts and passwords and is supported for use with dse commands and the dsetool utility. Internal authentication is supported on the following clients when you provide a user name and password to start up the client:

  • Astyanax
  • cassandra-cli
  • cqlsh
  • Drivers
  • Hector
  • pycassa

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

Providing user credentials 

You can provide credentials in several ways:
Command line
Provide user login credentials on the command line: 
$ dse [-f config_file] [-u username -p password] [-a jmx_username -b jmx_password]  subcommand
$ dsetool [-f config_file] [-l username -p password] [-a jmx_username -b jmx_password]  subcommand
where:
  • dse -u username is the user name to authenticate against the configured Cassandra user.
  • dsetool -l username is the user name to authenticate against the configured Cassandra user.
  • -p password is the password to authenticate against the configured Cassandra user. If you do not provide a password on the command line, you are prompted to enter one.
  • -a jmx_username is the user name for authenticating with secure JMX.
  • -b jmx_username is the password for authenticating with secure JMX. If you do not provide a password on the command line, you are prompted to enter one.
  • -f config_file is the path to a configuration file that stores credentials. If not specified, then use ~/.dserc if it exists.
    The configuration file can contain Cassandra and JMX login credentials. For example:
    username=cassandra
password=cassandra
jmx_username=cassandra
jmx_password=jmx
    The credentials in the configuration file are stored in clear text. DataStax recommends restricting access to this file only to the specific user.
When the password is not specified, you are prompted to enter the passwords on the next line. For example:
$ dse -u cassandra hadoop fs -ls /
prompts you to enter the password to authenticate against the configured Cassandra authentication schema.
~/.dserc file
Create a file named .dserc in your home directory. The ~/.dserc file contains the Cassandra user name and password:
username=username
password=password

When the user launches a password-protected tool and authentication is not provided on the command line, the user name and password in the ~/.dserc file is used. The ~/.dserc is ignored when a configuration file is specified with -f.

Spark component limitations 

DataStax Enterprise provides internal authentication support for some Hadoop tools and for connecting Spark to Cassandra, not authenticating Spark components between each other.

Authentication for Spark-to-Cassandra connection  

After configuring authentication, create a ~/.dserc file to authenticate the Spark-to-Cassandra connection. If a ~/.dserc file does not exist, use these options on the command line with Spark commands to provide the login credentials.

Note: You must include the IP host as part of the connection, as specified in the listen_address or rpc_address.

Using passwords to launch Spark

If a ~/.dserc file does not exist, use these options on the dse command line to provide the login credentials: 
$ dse -u username -p password spark

Hadoop tool authentication  

After configuring authentication, starting Hadoop requires a user name and password. These login credentials can be provided using a ~/.dserc file or a command line option.

The following authentication limitations apply when using Hadoop tools:
  • Internal authentication is not supported for Mahout.
  • Using internal authentication to run the hadoop jar command is not supported.

    The hadoop jar command accepts only the JAR file name as an option, and rejects other options such as username and password. The main class in the jar is responsible for making sure that the credentials are applied to the job configuration.

  • In Pig scripts that use the custom storage handlers CqlNativeStorage and CassandraStorage, provide credentials in the URL of the URL-encoded prepared statement:

    cql://username:password@keyspace/columnfamily
cassandra://username:password@keyspace/columnfamily

    Use this method of providing authentication for Pig commands regardless of the mechanism that is used to pass credentials to Pig.

  • To use Hadoop tools, such as Hive, a user who is not a superuser needs all privileges to HiveMetaStore and cfs keyspaces. To configure a user account named jdoe, for example, to use Hadoop tools, use these cqlsh commands:
    cqlsh> GRANT ALL PERMISSIONS ON KEYSPACE "HiveMetaStore" TO jdoe;
cqlsh> GRANT ALL PERMISSIONS ON KEYSPACE cfs TO jdoe;

Authenticating with Beeline 

Use these options on the dse command line to provide the login credentials for beeline. The dse password is not checked by the Hive Thrift server in the default configuration. You must authenticate with the Cassandra user and password when you connect with JDBC:
$ dse -u username -p password beeline 
!connect jdbc:hive2://localhost:10000?cassandra.username=username;cassandra.password=password

Authenticating Shark configuration 

Use the following command to provide the login credentials when configuring Shark.
$ dse shark -hiveconf cassandra.username=<username> -hiveconf cassandra.password=<password>