Cassandra JMX Authentication & Authorization: Create User

There are two types of security in Apache Cassandra and DataStax Enterprise.

• Internal Authentication
• Authorization

What is Internal Authentication and Authorization

Internal authentication is basically validating a user connection. The user is authenticated with login and password. All the user accounts are managed in Cassandra internally.

Internal authorization deals with a user’s permission. It deals with what actions a user can perform. For example, we can give permissions such as which user has only data read permission, which user has data write permission and which user has data delete permission.

However, authentication can also be controlled externally with Kerberos (Kerberos is used to manage credentials securely) and LDAP (LDAP is used for holding authoritative information about the accounts, such as what they’re allowed to access).

External authentication is the authentication that is supported with Kerberos and LDAP. Apache Cassandra does not support external authentication.

Only DataStax Enterprise supports external authentication with Kerberos and LDAP, whereas internal authentication is supported both in Apache Cassandra as well as DataStax Enterprise.

Configure Authentication and Authorization

In Cassandra, by default authentication and authorization options are disabled. You have to configure the cassandra.yaml file for enabling authentication and authorization.

Open cassandra.yaml and uncomment the lines that deal with internal authentication and authorization, as shown below.

• In cassandra.yaml, by default, the authenticator value is ‘AllowAllAuthenticator’. Change this authenticator value from ‘AllowAllAuthenticator’ to ‘com.datastax.bdp.cassandra.auth.PasswordAuthenticator’.
• Similarly, in cassandra.yaml, by default, the authorizer value will be ‘AllowAllAuthorizer’. Change this authorizer value from ‘AllowAllAuthorizer’ to ‘com.datastax.bdp.cassandra.auth.CassandraAuthorizer’.

Those two class names are the DataStax Enterprise values. On open-source Apache Cassandra the same settings take PasswordAuthenticator and CassandraAuthorizer, and credentials then live in the system_auth keyspace, whose replication factor should be raised above one.

Logging in

Now authentication is enabled, if you try to access any keyspace, Cassandra will return an error.

By default, Cassandra provides the super account with user name ‘cassandra’ and password ‘cassandra’. By logging in to the ‘cassandra’ account, you can do whatever you want.

Let’s see the below screenshot for this, where it will not allow you to login if you are not using the default Cassandra “username” and “password”.

Now, in the second screenshot, you can see after using the Cassandra default login credential, you are able to login.

You can also create another user with this account. It is recommended to change the password from the default. Here is the example of logging in as the Cassandra user and changing the default password.

alter user cassandra with password 'newpassword';

Create New User

New accounts can be created with the ‘cassandra’ account.

For creating a new user, the login and password are specified along with whether the user is a superuser or not. Only a superuser can create new users.

create user robin with password 'manager' superuser;
create user robin with password 'newhire';

You can get a list of all users by the following syntax.

list users;

The output lists every account together with its superuser flag.

Users can be dropped by the following syntax.

drop user laura;

Authorization

Authorization is the assigning of permission to users, deciding what action a particular user can perform.

Here is the generic syntax for assigning permission to users.

GRANT permission ON resource TO user

There are following types of permission that can be granted to the user.

1. ALL
2. ALTER
3. AUTHORIZE
4. CREATE
5. DROP
6. MODIFY
7. SELECT

Here are examples of assigning permission to the user.

Create user laura with password 'newhire'; 
grant all on dev.emp to laura;
revoke all on dev.emp to laura;
grant select on dev.emp to laura;

A new user ‘laura’ is created with password ‘newhire’.

Here is the example where user ‘laura’ tries to access the emp_bonus table. Laura has only permission to access dev.emp and no permission on the table dev.emp_bonus, which is why an error was returned.

select* form emp_bonus;

You can get a list of all permissions that are assigned to the user. Here is the example of getting permission information.

list all permissions of laura;

You can also list all the permissions on a resource. Here is the example of getting permission from a table.

list all permissions on dev.emp;

Configuring Firewall

If the firewall is running, following ports must be opened for communication between nodes including some Cassandra ports. If Cassandra ports will not be opened, Cassandra nodes will act as standalone database servers rather than joining the database cluster.

Cassandra Client Ports

Cassandra Internode ports

Public Ports

Cassandra OpsCenter ports

Current drivers use only 9042; port 9160 serves the legacy Thrift interface and can stay closed on new clusters.

Enabling JMX Authentication

With the default settings of Cassandra, JMX can only be accessed from the localhost. If you want to access JMX remotely, change the LOCAL_JMX setting in cassandra-env.sh and enable authentication or SSL.

After enabling JMX authentication, make sure OpsCenter and nodetool are configured to use authentication.

Procedure

There are following steps for enabling JMX authentication.

1. In the cassandra-env.sh file, add or update following lines.

   JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.authenticate=true"
   JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password"

   Also, change the LOCAL_JMX setting in cassandra-env.sh.

   LOCAL_JMX=no

2. Copy the jmxremote.password.template from /jdk_install_location/lib/management/ to /etc/cassandra/ and rename it to jmxremote.password.

   cp /jdk_install_dir/lib/management/jmxremote.password.template /etc/cassandra/jmxremote.password

3. Change the ownership of jmxremote.password to the user you run Cassandra with and change permission to read only.

   chown cassandra:cassandra /etc/cassandra/jmxremote.password 
   chmod 400 /etc/cassandra/jmxremote.password

4. Edit jmxremote.password and add the user and password for JMX-compliant utilities:

   monitorRole QED 
   controlRole R&D 
   cassandra cassandrapassword

5. Add the Cassandra user with read and write permission to /jdk_install_location/lib/management/jmxremote.access

   monitorRole readonly
   cassandra readwrite
   controlRole readwrite \
   create javax.management.monitor.,javax.management.timer. \ 
   unregister

6. Restart Cassandra.
7. Run nodetool with the Cassandra user and password.

   $ nodetool status -u cassandra -pw cassandra

FAQs