DataStax Developer Blog

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

By Robin Schumacher -  February 26, 2013 | 10 Comments

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.



Comments

  1. sanjay says:

    I am sure I can secure keyspace through CQL, how does it work other drivers like JDBC, ODBC, thrift and other clients. Is the access info must be provided in the URl or something. Please provide more details, This page does not list all other details.

    Thanks

  2. Robin Schumacher Robin Schumacher says:

    It depends on the driver. For example the DataStax Java and .NET clients support security as does Hector, however the ODBC drivers developed by Simba currently do not. For more general information on security, see: http://www.datastax.com/docs/datastax_enterprise3.1/security/index. We’re adding security sections to both our new Java and .NET drivers docs now, so hopefully that will be posted in a few days.

    1. Phani says:

      Hi Robin,
      I was trying to connect my cassandra secure cluster with kerberos enabled with Datastax java driver but I could not find any documentation on that. Could please help me if you had any?

  3. Victor says:

    Wondering how you would actually secure a full KEYSPACE in CQL. All the docs state that you can do it at the table (CF) level, and nothing has pointed me in the right direction.

    I have tried:

    cqlsh> GRANT ALL ON TO ;
    Bad Request: <table .> doesn't exist

    cqlsh> GRANT ALL ON .* TO ;
    Bad Request: line 1:22 no viable alternative at input '*'

  4. sanjay says:

    Recent text for the Datastx Forums
    Sorry for the delay and that you were inconvenienced by the outdated material.

    GRANT PERMISSIONS
    Provides users access to database objects.

    GRANT ALL| ALL PERMISSIONS permission_name PERMISSION ON resource TO user WITH GRANT OPTION

    (there are options in this syntax that don’t copy over)

    permission_name is one of these:

    ALL
    ALL PERMISSIONS
    ALTER
    AUTHORIZE
    CREATE
    DROP
    FULL_ACCESS
    MODIFY
    NO_ACCESS
    SELECT

    resource is one of these:

    ALL KEYSPACES
    KEYSPACE keyspace_name
    TABLE keyspace_name.table_name

    Description

    Permissions to access all keyspaces, a named keyspace, or a table can be granted to a user. This table lists the permissions needed to use cqlsh statements:

    Permission cqlsh 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

    The authorize permission gives a user the ability to grant access with the grant option, not just grant permissions to other users. Currently granting permissions on indexes and configuration options are not available at this time.

    Examples

    Give ‘bashful’ permission to perform SELECT queries on all tables in all keyspaces:

    GRANT SELECT ON ALL KEYSPACES TO bashful;
    Give ‘dopey’ permission to perform INSERT, UPDATE, DELETE and TRUNCATE queries on all tables in the ‘woods’ keyspace:

    GRANT MODIFY ON KEYSPACE woods TO dopey;
    Give ‘doc’ permission to perform ALTER KEYSPACE queries on the ‘mines’ keyspace, and also ALTER TABLE, CREATE INDEX and DROP INDEX queries on all tables in ‘mines’ keyspace:

    GRANT ALTER ON KEYSPACE mines TO doc;
    Give ‘doc’ permission to run all types of queries on cottage.chores table:

    GRANT ALL PERMISSIONS ON cottage.chores TO doc;
    SELECT permission

    Permissions checks are recursive: To be able to perform SELECT queries on ‘my_table’ you have to have SELECT permission on the table OR on its parent keyspace OR on ALL KEYSPACES.

    CREATE permission

    To be able to CREATE TABLE you need CREATE permission on its parent keyspace or ALL KEYSPACES. etc. To be able to CREATE KEYSPACE you need CREATE permission on ALL KEYSPACES.

    GRANT, REVOKE, and LIST

    To grant access to a keyspace to just one user, assuming nobody else has ALL KEYSPACES access, you use this statement:

    GRANT ALL ON KEYSPACE keyspace_name TO user_name
    GRANT, REVOKE and LIST check for table/keyspace existence before execution. GRANT and REVOKE check for user existence after IAuthenticator rewrite is complete.

    REVOKE PERMISSIONS

    REVOKE ALL| ALL PERMISSIONS permission_name PERMISSION ON resource FROM user_name
    permission_name is one of these:

    ALL
    ALL PERMISSIONS
    ALTER
    AUTHORIZE
    CREATE
    DROP
    FULL_ACCESS
    MODIFY
    NO_ACCESS
    SELECT

    resource is one of these:

    ALL KEYSPACES
    KEYSPACE keyspace_name
    TABLE keyspace_name.table_name

    Description

    Permissions to access all keyspaces, a named keyspace, or a table can be revoked from a user. This table lists the permissions needed to use cqlsh statements:

    Permission cqlsh 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

    Example

    REVOKE SELECT ON cottage.chores FROM doc;

    The user doc can no longer perform SELECT queries on the cottage.chores table.

  5. Vijay says:

    Hi,
    i have created below keyspace and table. However when i create ODBC connection i am unable to see the table in schema definition. can you please help how to see the table or list of tables?

    keyspace
    ————-
    create keyspace Ikeys with replication={‘class’:'SimpleStrategy’,'replication_factor’:2};

    table
    ——-
    CREATE TABLE monkeySpecies (
    species text PRIMARY KEY,
    common_name text,
    population varint,
    average_size int
    ) WITH comment=’Important biological records’
    AND read_repair_chance = 1.0;

  6. Robin Schumacher Robin Schumacher says:

    Vijay – the current ODBC driver for Cassandra is alpha currently and not recommended for anything other than testing. For daily dev work, I recommend you download and use our free DevCenter tool, which allows you to create objects, issue CQL statements, navigate keyspaces, and more: http://www.datastax.com/what-we-offer/products-services/devcenter.

  7. Vijay says:

    Hi Robin
    Thanks for early response however when i install Datastax developer tools i can only open Devcenter editor however unable to find the ODBC driver in ODBC Administrator.
    I am using windows 7 Version.
    Can you please tell me in detail what i can choose and download the ODBC driver.

  8. Vijay says:

    Hi,
    How to create Keyspace using LocalStrategy in Datastax Developer tool

  9. Lakshmi says:

    Hi,
    Can you please provide details of Datstax Devecenter connection manger dates .
    Connection Name
    Contact hosts
    Native protocal Port

    Security:
    Login credentials

    Ragards,
    Lakshmi

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>