Security¶

Inter-node Encryption¶

The settings for managing inter-node encryption are found in cassandra.yaml in the server_encryption_options section. To enable inter-node encryption, change the internode_encryption setting from its default value of none to one value from: rack, dc or all.

Client to Node Encryption¶

The settings for managing client to node encryption are found in cassandra.yaml in the client_encryption_options section. There are two primary toggles here for enabling encryption, enabled and optional.

• If neither is set to true, client connections are entirely unencrypted.
• If enabled is set to true and optional is set to false, all client connections must be secured.
• If both options are set to true, both encrypted and unencrypted connections are supported using the same port. Client connections using encryption with this configuration will be automatically detected and handled by the server.

As an alternative to the optional setting, separate ports can also be configured for secure and unsecure connections where operational requirements demand it. To do so, set optional to false and use the native_transport_port_ssl setting in cassandra.yaml to specify the port to be used for secure client communication.

Enabling Password Authentication¶

Before enabling client authentication on the cluster, client applications should be pre-configured with their intended credentials. When a connection is initiated, the server will only ask for credentials once authentication is enabled, so setting up the client side config in advance is safe. In contrast, as soon as a server has authentication enabled, any connection attempt without proper credentials will be rejected which may cause availability problems for client applications. Once clients are setup and ready for authentication to be enabled, follow this procedure to enable it on the cluster.

Pick a single node in the cluster on which to perform the initial configuration. Ideally, no clients should connect to this node during the setup process, so you may want to remove it from client config, block it at the network level or possibly add a new temporary node to the cluster for this purpose. On that node, perform the following steps:

1. Open a cqlsh session and change the replication factor of the system_auth keyspace. By default, this keyspace uses SimpleReplicationStrategy and a replication_factor of 1. It is recommended to change this for any non-trivial deployment to ensure that should nodes become unavailable, login is still possible. Best practice is to configure a replication factor of 3 to 5 per-DC.

ALTER KEYSPACE system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'DC1': 3, 'DC2': 3};

2. Edit cassandra.yaml to change the authenticator option like so:

authenticator: PasswordAuthenticator

3. Restart the node.
4. Open a new cqlsh session using the credentials of the default superuser:

cqlsh -u cassandra -p cassandra

5. During login, the credentials for the default superuser are read with a consistency level of QUORUM, whereas those for all other users (including superusers) are read at LOCAL_ONE. In the interests of performance and availability, as well as security, operators should create another superuser and disable the default one. This step is optional, but highly recommended. While logged in as the default superuser, create another superuser role which can be used to bootstrap further configuration.

# create a new superuser
CREATE ROLE dba WITH SUPERUSER = true AND LOGIN = true AND PASSWORD = 'super';

6. Start a new cqlsh session, this time logging in as the new_superuser and disable the default superuser.

ALTER ROLE cassandra WITH SUPERUSER = false AND LOGIN = false;

7. Finally, set up the roles and credentials for your application users with CREATE ROLE statements.

At the end of these steps, the one node is configured to use password authentication. To roll that out across the cluster, repeat steps 2 and 3 on each node in the cluster. Once all nodes have been restarted, authentication will be fully enabled throughout the cluster.

Note that using PasswordAuthenticator also requires the use of CassandraRoleManager.

See also: Setting credentials for internal authentication, CREATE ROLE, ALTER ROLE, ALTER KEYSPACE and GRANT PERMISSION,

Enabling Internal Authorization¶

Permissions are modelled as a whitelist, with the default assumption that a given role has no access to any database resources. The implication of this is that once authorization is enabled on a node, all requests will be rejected until the required permissions have been granted. For this reason, it is strongly recommended to perform the initial setup on a node which is not processing client requests.

The following assumes that authentication has already been enabled via the process outlined in Enabling Password Authentication. Perform these steps to enable internal authorization across the cluster:

1. On the selected node, edit cassandra.yaml to change the authorizer option like so:

authorizer: CassandraAuthorizer

2. Restart the node.
3. Open a new cqlsh session using the credentials of a role with superuser credentials:

cqlsh -u dba -p super

4. Configure the appropriate access privileges for your clients using GRANT PERMISSION statements. On the other nodes, until configuration is updated and the node restarted, this will have no effect so disruption to clients is avoided.

GRANT SELECT ON ks.t1 TO db_user;

5. Once all the necessary permissions have been granted, repeat steps 1 and 2 for each node in turn. As each node restarts and clients reconnect, the enforcement of the granted permissions will begin.

See also: GRANT PERMISSION, GRANT ALL <grant-all> and REVOKE PERMISSION

Standard JMX Auth¶

Users permitted to connect to the JMX server are specified in a simple text file. The location of this file is set in cassandra-env.sh by the line:

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

Edit the password file to add username/password pairs:

jmx_user jmx_password

Secure the credentials file so that only the user running the Cassandra process can read it :

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

Optionally, enable access control to limit the scope of what defined users can do via JMX. Note that this is a fairly blunt instrument in this context as most operational tools in Cassandra require full read/write access. To configure a simple access file, uncomment this line in cassandra-env.sh:

#JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.access.file=/etc/cassandra/jmxremote.access"

Then edit the access file to grant your JMX user readwrite permission:

jmx_user readwrite

Cassandra must be restarted to pick up the new settings.

See also : Using File-Based Password Authentication In JMX

Cassandra Integrated Auth¶

An alternative to the out-of-the-box JMX auth is to useeCassandra’s own authentication and/or authorization providers for JMX clients. This is potentially more flexible and secure but it come with one major caveat. Namely that it is not available until after a node has joined the ring, because the auth subsystem is not fully configured until that point However, it is often critical for monitoring purposes to have JMX access particularly during bootstrap. So it is recommended, where possible, to use local only JMX auth during bootstrap and then, if remote connectivity is required, to switch to integrated auth once the node has joined the ring and initial setup is complete.

With this option, the same database roles used for CQL authentication can be used to control access to JMX, so updates can be managed centrally using just cqlsh. Furthermore, fine grained control over exactly which operations are permitted on particular MBeans can be acheived via GRANT PERMISSION.

To enable integrated authentication, edit cassandra-env.sh to uncomment these lines:

#JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.remote.login.config=CassandraLogin"
#JVM_OPTS="$JVM_OPTS -Djava.security.auth.login.config=$CASSANDRA_HOME/conf/cassandra-jaas.config"

And disable the JMX standard auth by commenting this line:

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

To enable integrated authorization, uncomment this line:

#JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.authorizer=org.apache.cassandra.auth.jmx.AuthorizationProxy"

Check standard access control is off by ensuring this line is commented out:

#JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.access.file=/etc/cassandra/jmxremote.access"

With integrated authentication and authorization enabled, operators can define specific roles and grant them access to the particular JMX resources that they need. For example, a role with the necessary permissions to use tools such as jconsole or jmc in read-only mode would be defined as:

CREATE ROLE jmx WITH LOGIN = false;
GRANT SELECT ON ALL MBEANS TO jmx;
GRANT DESCRIBE ON ALL MBEANS TO jmx;
GRANT EXECUTE ON MBEAN 'java.lang:type=Threading' TO jmx;
GRANT EXECUTE ON MBEAN 'com.sun.management:type=HotSpotDiagnostic' TO jmx;

# Grant the role with necessary permissions to use nodetool commands (including nodetool status) in read-only mode
GRANT EXECUTE ON MBEAN 'org.apache.cassandra.db:type=EndpointSnitchInfo' TO jmx;
GRANT EXECUTE ON MBEAN 'org.apache.cassandra.db:type=StorageService' TO jmx;

# Grant the jmx role to one with login permissions so that it can access the JMX tooling
CREATE ROLE ks_user WITH PASSWORD = 'password' AND LOGIN = true AND SUPERUSER = false;
GRANT jmx TO ks_user;

Fine grained access control to individual MBeans is also supported:

GRANT EXECUTE ON MBEAN 'org.apache.cassandra.db:type=Tables,keyspace=test_keyspace,table=t1' TO ks_user;
GRANT EXECUTE ON MBEAN 'org.apache.cassandra.db:type=Tables,keyspace=test_keyspace,table=*' TO ks_owner;

This permits the ks_user role to invoke methods on the MBean representing a single table in test_keyspace, while granting the same permission for all table level MBeans in that keyspace to the ks_owner role.

Adding/removing roles and granting/revoking of permissions is handled dynamically once the initial setup is complete, so no further restarts are required if permissions are altered.

See also: Permissions.

JMX With SSL¶

JMX SSL configuration is controlled by a number of system properties, some of which are optional. To turn on SSL, edit the relevant lines in cassandra-env.sh (or cassandra-env.ps1 on Windows) to uncomment and set the values of these properties as required:

com.sun.management.jmxremote.ssl

set to true to enable SSL

com.sun.management.jmxremote.ssl.need.client.auth

set to true to enable validation of client certificates

com.sun.management.jmxremote.registry.ssl

enables SSL sockets for the RMI registry from which clients obtain the JMX connector stub

com.sun.management.jmxremote.ssl.enabled.protocols

by default, the protocols supported by the JVM will be used, override with a comma-separated list. Note that this is not usually necessary and using the defaults is the preferred option.

com.sun.management.jmxremote.ssl.enabled.cipher.suites

by default, the cipher suites supported by the JVM will be used, override with a comma-separated list. Note that this is not usually necessary and using the defaults is the preferred option.

javax.net.ssl.keyStore

set the path on the local filesystem of the keystore containing server private keys and public certificates

javax.net.ssl.keyStorePassword

set the password of the keystore file

javax.net.ssl.trustStore

if validation of client certificates is required, use this property to specify the path of the truststore containing the public certificates of trusted clients

javax.net.ssl.trustStorePassword

set the password of the truststore file

See also: Oracle Java7 Docs, Monitor Java with JMX