Enabling authentication and authorization
By default, Cassandra does not require user authentication when clients connect to the cluster, and it also does not place any restriction on the ability of clients to perform operations on the database. To change this, we will need to make a couple of minor modifications to our Cassandra instance's configuration file. Since modifications to the configuration file are typically a concern of deployment engineers, we haven't interacted with it in this book, so you may be wondering where to find it. Where it's located depends on your platform; the table below assumes you installed Cassandra using the instructions for your platform in the Installing Cassandra section of Chapter 1, Getting Up and Running with Cassandra. The following table gives you the location of the cassandra.yaml file on the respective platforms.
|
Platform |
Configuration file location |
|---|---|
|
Mac OS X |
|
|
Ubuntu |
|
|
Windows |
|
You will need to make two changes to the cassandra.yaml file. First, find the line that begins with authenticator: and change it to:
authenticator: PasswordAuthenticator
This change tells Cassandra to require a username and password when clients connect to the cluster. It does not, however, restrict access based on which user is logged in; to do that, we'll need to enable authorization. Find the line beginning with authorizer: and change it to:
authorizer: CassandraAuthorizer
Now our cluster will restrict the access of the logged in user based on the permissions that user has been granted. You will need to restart your Cassandra instance for the settings to take effect.
Authentication, authorization, and fault tolerance
Using the PasswordAuthenticator and CassandraAuthorizer strategies for authentication and authorization respectively, user credentials and granted permissions are stored in Cassandra itself. This means that, if the authentication data becomes unavailable, no clients will be able to access the cluster. For that reason, you will always want to set the replication factor for your system_auth keyspace to the total number of nodes in your cluster. Since our development cluster consists of only a single node, we don't need to make any changes; in production, however, you will almost certainly have many nodes in your cluster, and you'll want to make sure credentials and permissions are stored locally on every one of them.
Note
For further information on configuring Cassandra authentication, including best practices when configuring authentication in a production cluster, see the DataStax Cassandra documentation at http://www.datastax.com/documentation/cassandra/2.1/cassandra/security/security_config_native_authenticate_t.html.
For more information on configuring authorization, see http://www.datastax.com/documentation/cassandra/2.1/cassandra/security/secure_config_native_authorize_t.html.
Authentication with cqlsh
Now that we've enabled authentication on our development cluster, we will need to reconnect our cqlsh session with a username and password. By default, Cassandra has a superuser account whose username and password are both cassandra, so we can use that:
$ cqlsh -u cassandra -p cassandra
In a production cluster, of course, we would not want to have a superuser account with such an easily guessable password; however, for our purposes, this will work fine.
Authentication in your application
The details differ from language to language, but the CQL driver for your platform should provide a mechanism for authenticated connections. Consult your driver's documentation for more information.
