Configuring and using internal authentication
Internal authentication is based on Cassandra-controlled login accounts and passwords. You can authenticate uses of Hadoop tools, Spark-to-Cassandra connections, and Shark configuration changes.
Like object permission management that uses internal authorization, internal authentication is based on Cassandra-controlled login accounts and passwords. 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
- DataStax Java and C# drivers
- Hector
- pycassa
Internal authentication stores user names and bcrypt-hashed passwords in the system_auth.credentials table. You can authenticate uses of Hadoop tools, Spark-to-Cassandra connections, and Shark configuration changes.
Limitations
DataStax Enterprise provides internal authentication support for some Hadoop tools and for connecting Spark to Cassandra, not authenticating Spark components between each other.
Using a file to provide credentials
username=<username>
password=<password>
When
the user launches a password-protected tool, DataStax Enterprise uses the user name
and password in the ~/.dserc file.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.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 spark -Dcassandra.username=<username> -Dcassandra.password=<password>
dse spark-with-cc -Dcassandra.username=<username> -Dcassandra.password=<password>
dse spark-schema -Dcassandra.username=<username> -Dcassandra.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>
Authentication for Hadoop tools
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.
Using the command line
dse hadoop <command> -Dcassandra.username=<username> -Dcassandra.password=<password> <other options>
dse hive <hive options> -hiveconf cassandra.username=<username> -hiveconf cassandra.password=<password>
dse pig -Dcassandra.username=<username> -Dcassandra.password=<password> <pig options>
dse sqoop <sqoop options> --cassandra-username=<username> --cassandra-password=<password>
The dse command reference covers other
options.Hadoop tool authentication limitations
- 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 CqlStorage and CassandraStorage storage handlers, 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 you use for passing 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;