A Quick Tour of Internal Authentication and Authorization Security in DataStax Enterprise and Apache Cassandra

Security has been a notable weakness in nearly every NoSQL database, a fact that was highlighted in a 2012 InformationWeek special report entitled “Why NoSQL Equals No Security.” Recognizing that a comprehensive security framework is needed for NoSQL, and due to very high demand from both customers and the open source community, we decided to make security one of the key areas of focus for version 3.0 of DataStax Enterprise and Cassandra.

This article will concentrate on the new internal authentication and authorization (or permission management) features that are part of both open source Cassandra as well as DataStax Enterprise. Authentication deals with validating incoming user connections to a database cluster, whereas authorization concerns itself with what a logged in user can do inside a database. For more information on both of these, see our Apache Cassandra online docs.

What is Internal Authentication and Authorization?

Internal authentication equates to having user login accounts and their passwords being managed inside Cassandra. Another way of controlling authentication is through external security software such as Kerberos and LDAP. External authentication is supported by DataStax Enterprise (DSE) whereas internal authentication is supported both by DSE and open source Cassandra.

Internal authorization is where a user’s permissions – what actions they can perform inside the database – are enforced and managed inside of Cassandra.

Configuring Authentication and Authorization

Built-in Cassandra-based internal authentication and authorization is not enabled by default. Configuring them for use is very easy and involves simply editing the cassandra.yaml file and uncommenting two configuration parameters that control Cassandra internal authentication and authorization (examples shown throughout this article are those used with DataStax Enterprise, but the same general facts apply to open source Cassandra as well; for example, in Cassandra the namespace for password authentication and authorization is org.apache.cassandra.auth vs com.datastax.bdp.cassandra.auth):

# authentication backend, implementing IAuthenticator; used to identify users

#authenticator: org.apache.cassandra.auth.AllowAllAuthenticator

authenticator: com.datastax.bdp.cassandra.auth.PasswordAuthenticator

# authorization backend, implementing IAuthorizer; used to limit access/provide permissions

#authorizer: org.apache.cassandra.auth.AllowAllAuthorizer

authorizer: com.datastax.bdp.cassandra.auth.CassandraAuthorizer

Once these changes are made and saved to the cassandra.yaml file, the database cluster can be started/re-started so that internal authentication and authorization are now enabled.

As an aside, let me mention that the Cassandra-based authentication and authorization are just one possible implementation of these types of security enforcements; you have the flexibility to create/use others if you'd like. Also, you have the option of using authentication without authorization if you choose. Some of you told us you just want users authenticated to a database with no further enforcement, so we've provided that flexibility.

 

Logging In

With internal authentication enabled, a user must login to perform any actions on the database cluster:

robinsmac:bin robin$ ./cqlsh

Connected to Test Cluster at localhost:9160.

[cqlsh 2.2.0 | Cassandra unknown | CQL spec 2.0.0 | Thrift protocol 19.33.0]

Use HELP for help.

cqlsh> use dev;

Bad Request: You have not logged in

By default, each installation of Cassandra or DataStax Enterprise includes a “superuser” account named cassandra, whose password is also ‘cassandra’. This account allows a user to perform any action on the database cluster and create new login accounts. It’s recommended that the password be changed from the default. An example of logging in and altering the default password for the cassandra superuser might be:

robinsmac:bin robin$ ./cqlsh -3 localhost -u cassandra -p cassandra

Connected to Test Cluster at localhost:9160.

[cqlsh 2.2.0 | Cassandra 1.1.9.1-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol 19.33.0]

Use HELP for help.

cqlsh> alter user cassandra with password 'newpassword';

To avoid having to pass an ID/password combination every time a login with the CQL utility is done, a ~.cqlshrc file can be created and stored in a user’s home directory. When present, it can pass default login information to the CQL utility. A sample file looks like this:

; Sample ~/.cqlshrc file.

[authentication]

username = fred

password = !!bang!!$

...

Naturally, this file should be secured so that no one can easily gain access to database login information.

 

Creating New Login Accounts

Creating new login accounts is very straightforward. A login name and password are specified along with whether the new user is a superuser or general user:

cqlsh> create user robin with password 'manager' superuser;

cqlsh> create user laura with password 'newhire';

Getting a listing of all login accounts can be done using the list command:

cqlsh> list users;

name      | super

----------+-------

cassandra | True

laura     | False

robin     | True

Users are removed via the drop command:

cqlsh> drop user laura;

Using Internal Authorization

Authorization (or permission management) is handled in DataStax Enterprise and Cassandra through the very familiar RDBMS GRANT/REVOKE paradigm:

GRANT permission ON resource TO user  

Possible permissions that can be granted currently include:

• ALL
• ALTER
• AUTHORIZE
• CREATE
• DROP
• MODIFY
• SELECT

The various permission/resource combinations currently are:

Permission	CQL Statements
ALTER	ALTER KEYSPACE, ALTER TABLE, CREATE INDEX, DROP INDEX
AUTHORIZE	GRANT, REVOKE
CREATE	CREATE KEYSPACE, CREATE TABLE
DROP	DROP KEYSPACE, DROP TABLE
MODIFY	INSERT, DELETE, UPDATE, TRUNCATE
SELECT	SELECT

 

An example of grant/revoking permissions to a new user might be:

cqlsh> create user laura with password 'newhire';

cqlsh> grant all on dev.emp to laura;

cqlsh> revoke all on dev.emp from laura;

cqlsh> grant select on dev.emp to laura;

The new 'laura' user account can login, read data from the emp table, but cannot perform other actions such as reading data from another table for which it has not been granted rights:

robinsmac:bin robin$ ./cqlsh -3 localhost -u laura -p newhire

Connected to Test Cluster at localhost:9160.

[cqlsh 2.2.0 | Cassandra 1.1.8.1-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol 19.33.0]

Use HELP for help.

cqlsh> use dev;

cqlsh:dev> select * from emp;

empid | empname

------+---------

1     |   robin

2     |   laura

cqlsh:dev> select * from emp_bonus;

Bad Request: User laura has no SELECT permission on <table dev.emp_bonus> or any of its parents

Finding out what login accounts possess what permissions on what objects and what objects have permissions granted on them is performed through various list commands (as long as the user has the authority to use them):

cqlsh> list all permissions of laura;

username | resource        | permission

---------+-----------------+------------

laura    | <table dev.emp> |     SELECT

cqlsh> list all permissions on dev.emp;

username | resource        | permission

---------+-----------------+------------

laura    | <table dev.emp> |     SELECT

 

Authentication and Authorization Metadata Storage

Information regarding login accounts and permissions are stored in various system objects in a system keyspace that’s maintained by Cassandra. Some of these objects are off limits to all users whereas others may be queried via CQL:

cqlsh> use dse_auth;

cqlsh:dse_auth> describe keyspace dse_auth;

CREATE TABLE users (

name text PRIMARY KEY,

super Boolean

)

…

CREATE TABLE permissions (

username text,

resource text,

permission text,

x int,

PRIMARY KEY (username, resource, permission)

)

…

CREATE TABLE credentials (

username text PRIMARY KEY,

salted_hash text

)

…

cqlsh:dse_auth> select * from users;

name       | super

-----------+-------

cassandra  | True

laura      | False

robin      | True

 

Next Steps

To try out internal authentication and permission management in either Cassandra or DataStax Enterprise, download a copy today. DataStax Enterprise is completely free to use in development environments with no restrictions, however production deployments do require that a subscription be purchased. For more information, see our online documentation.