In all the NoSQL databases, Security has been a weak point. No NoSQL database provides complete security.
After recognizing this weak point in Cassandra and due to very high demands from customers and open source community, Apache Cassandra and Datastax enterprise decided to provide security feature in Apache Cassandra and Datastax enterprise.
In this tutorial, you will learn,
There are two types of security in Apache Cassandra and Datastax enterprise.
- Internal Authentication
Internal authentication is basically validating user connection. The user is authenticated with login and password. All the user accounts are managed in Cassandra internally.
Internal authorization deals with user's permission. It deals with what actions user can be performed. For example, we can give user's permission 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.
In Cassandra, by default authentication and authorization options are disabled. You have to configure Cassandra.yaml file for enabling authentication and authorization.
Open Cassandra.yaml file and uncomment lines that deals with internal authentication and authorization.
- In Cassandra.yaml file, by default, authenticator value is 'AllowAllAuthenticator'. Change this authenticator value from 'AllowAllAuthenticator' to 'com.datastax.bdp.cassandra.auth.PasswordAuthenticator'.
- Similarly, in Cassandra.yaml file, by default, authorizer value will be 'AllowAllAuthorizor'. Change this authorizer value from 'AllowAllAuthorizor' to 'com.datastax.bdp.cassandra.auth.CassandraAuthorizor'.
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 '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 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 login Cassandra user and change default password.
New accounts can be created with the 'Cassandra' account.
For creating a new user, login, the password is specified along with whether the user is super user or not. Only Super user can create new users.
You can get a list of all users by the following syntax.
Users can be dropped by the following syntax.
Authorization is the assigning permission to users that what action a particular user can perform.
Here is the generic syntax for assigning permission to users.
There are following types of permission that can be granted to the user.
Here are examples of assigning permission to the user.
A new user 'laura' is created with password 'newhire'.
Here is the example where user 'laura' try to access emp_bonus table. Laura has only permission to access dev.emp and no permission to this table dev.emp_bonus that's why an error was returned.
You can get a list of all permissions that is assigned to the user. Here is the example of getting permission information.
You can also list all the permission on the resource. Here is the example of getting permission from a table.
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 server rather than joining the database cluster.
Cassandra Client Ports
Cassandra Client Port
Cassandra Client Port Thrift
Cassandra Internode ports
Cassandra internode cluster communication
Cassandra SSL internode cluster communication
Cassandra JMX monitoring port
OpsCenter Website. Browser http request.
Cassandra OpsCenter ports
OpsCenter monitoring port.
Opscenter agent port
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.
There are following steps for enabling JMX authentication.
- In the cassandra-env.sh file, add or update following lines.
Also, change the LOCAL_JMX setting in Cassandra-env.sh
- Copy the jmxremote.password.template from /jdk_install_location/lib/management/ to /etc/cassandra/ and rename it tojmxremote.password.
- Change the ownership of jmxremote.password to the user you run Cassandra with and change permission to read only
- Edit jmxremote.password and add the user and password for JMX-compliant utilities:
- Add the Cassandra user with read and write permission to /jdk_install_location/lib/management/jmxremote.access
- Restart Cassandra
- Run nodetool with the Cassandra user and password.
This tutorial explains about security in Cassandra and configuring Cassandra.yaml file for enabling security. Besides this it also explains how new user account can be created, assignment of permission, configuring the firewall, and so on.