Setting up a user

By default, Cassandra has one user account configured; its username is cassandra and it is a superuser, meaning there are no restrictions on what it can do to the database. When you connect as a superuser, it's essentially the same as if Cassandra did not have authorization enabled at all.

In order to do something useful with our access restrictions, we'll want to set up another user account that is not a superuser. Let's say one of the departments in the burgeoning MyStatus corporation is a data analytics team. This team needs access to read data from our Cassandra cluster, but has no need to add, change, or remove data. We'll set up a user account for this team that gives them only the access they need.

First, we'll use the CREATE USER command to add a user account for the analytics team:

CREATE USER 'data_analytics'
WITH PASSWORD 'strongpassword'
NOSUPERUSER;

Note, of course, that in a real deployment we would want to choose an actual strong password, for which the string strongpassword does not suffice.

The NOSUPERUSER option tells Cassandra that the new account is not a superuser, meaning it can't do anything it hasn't explicitly been granted permission to do. This is the default for new users, but we make it explicit here for clarity; replacing it with SUPERUSER would make the new user a superuser.

Note

For more information on the CREATE USER command, see the DataStax CQL documentation: http://www.datastax.com/documentation/cql/3.1/cql/cql_reference/create_user_r.html.

Changing a user's password

If we wish to change the password of an existing account, we can use the ALTER USER command:

ALTER USER 'data_analytics'
WITH PASSWORD 'verystrongpassword';

We can also append a SUPERUSER or NOSUPERUSER option to the end of this query to grant or revoke superuser access.

Viewing user accounts

We can see existing user accounts, along with their superuser status, by accessing the users table in the system_auth keyspace:

SELECT * FROM "system_auth"."users";

Note that the use of the period between the keyspace name and the table name simply instructs CQL that we'd like to look into the system_auth keyspace, regardless of which keyspace, if any, has been activated by an USE statement.

As we can see, user accounts are stored quite transparently in the system_auth.users table:

You may be wondering where and how passwords are stored. These live in a separate table, system_auth.credentials; passwords are not stored in plain text, but rather as bcrypt hashes.