Configuring JMX Authentication
Java Management Extensions (JMX) technology provides a simple and standard way of managing and monitoring resources related to an instance of a Java Virtual Machine (JVM).
This is achieved by instrumenting resources with Java objects known as Managed Beans (MBeans) that are registered with an
DataStax Enterprise (DSE) supports authentication of JMX users and role-based access control to MBeans, see About DSE Unified Authentication.
DSE provides JMX authentication for
nodetool and external monitoring tools such as
To manage JMX client access, see Controlling access to JMX MBeans.
Java also provides local JMX authentication, which stores credentials and provides access control using a local file. When authenticate and authorization is disabled on the DSE, you can implement file based JMX remote authentication.
cassandra-env.sh file. The location of this file depends on the type of installation:
By default, JMX remote connections are disabled and JMX security authentication is disabled for both local and remote connections in the
DSE provides unified authentication from utilities such as
nodetool as well as external monitoring tools such as
JConsole that interface with the database using Java Management Extensions (JMX) MBeans.
To authorize access, see Controlling access to JMX MBeans.
DSE also supports local JMX authentication, which stores credentials and provides access control using a local file. When authenticate and authorization are disabled on DSE, you can implement file based JMX remote authentication.
To use DSE Unified Authentication for JMX users, complete Enabling DSE Unified Authentication.
Only use Java JMX remote authentication with local files in environments where DSE Unified Authentication and Role-Based Access Control (RBAC) are disabled.
On DSE nodes for which you want to allow access, set the JMX remote authenticate to
truefor remote or local, or both:
Connections are tested to see if they are local. Change the first instance to enable authentication on local connections and the second instance (in the else statement), to enable remote.
Disable local authentication by commenting out the following lines:
#JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password" #JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.access.file=/etc/cassandra/jmxremote.access"
To enable external authentication using DSE Authenticator, uncomment the following 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" JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.authorizer=org.apache.cassandra.auth.jmx.AuthorizationProxy"
Use the Java-provided local Java Management Extensions (JMX) authentication method, which stores credentials and controls access using a local file.
This implementation requires authentication to run utilities such as
When enabled, ensure that DSE Unified Authentication is disabled.
Generally, JMX settings are inserted into the
cassandra -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password
cassandra-env.shfile. The location of this file depends on the type of installation:
If it does not already exist, create the
/etc/cassandra directoryfrom an account with
sudo mkdir /etc/cassandra
Connections are tested to see if they are local; change the first instance to enable authentication on local connections and the second instance (in the else statement) to enable remote.
On DSE nodes where you want to disable JMX remote access, ensure
jmxremote.authenticateis set to
java.rmi.server.hostnamesetting, and change it to the IP address of the node to which you are connected. Example:
On nodes that allow access, set the path to the credentials file:
Ensure that the path is accessible to the user who runs as
jmxremote.passwordfile that contains a user name and password on each line and save it to the location entered in the previous step. Example:
Change the ownership and permission of the
chown cassandra:cassandra /etc/cassandra/jmxremote.password
chmod 400 /etc/cassandra/jmxremote.password
Optional: To limit the types of actions a user can perform, create a
jmxremote.accessfile, uncomment the
remote accessoption, and specify the path in the following setting:
If you enabled the remote access in this step, edit the
jmxremote.accessfile to include users and their proper permission level. Example:
cassandra readwrite <<new_superuser>> readwrite <<some_other_user>> readonly
superuseraccount is a security hazard! This account is used only for the purposes of illustration.
readonlypermission allows the JMX client to read an MBean’s attributes and receive notifications. The
readwritepermission allows the JMX client to set attributes, to invoke operations, and to create and remove MBeans, in addition to reading an MBean’s attributes and receiving notifications.
The access file must be secured from unauthorized readers. Change the ownership of the
jmxremote.accessfile to the user who starts
cassandra, and change permissions to
read only. Example:
chown cassandra:cassandra /etc/cassandra/jmxremote.access
chmod 400 /etc/cassandra/jmxremote.access
This example presumes that
cassandrais run by the default user
If all nodes on the cluster were updated, perform a rolling restart; otherwise restart only the affected nodes.
Verify that authentication is working by running a
nodetoolcommand with credentials:
nodetool -u cassandra -pw p4ssw0rd status
The results should display.
Datacenter: DataStax ===================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.200.182.180 316.76 KiB 1 ? 5ca115f6-250a-4964-9a52-c10926031f1b rack1 UN 10.200.182.181 446.76 KiB 1 ? 74a44407-5e26-43d4-83dc-aae9fe35c2f4 rack1 Datacenter: Solr ================ Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.200.182.183 368.38 KiB 1 ? d59d912c-dcc9-469f-8ae1-1c14313e16b1 rack1 Note: Non-system keyspaces don't have the same replication settings, effective ownership information is meaningless
Repeat the configuration on each node in the cluster.