• Glossary
  • Support
  • Downloads
  • DataStax Home
Get Live Help
Expand All
Collapse All

DataStax Enterprise 6.8 Security Guide

    • About DSE Advanced Security
    • Security FAQs
    • Security checklists
    • Securing the environment
      • Securing ports
      • Securing the TMP directory
    • Authentication and authorization
      • Configuring authentication and authorization
        • About DSE Unified Authentication
          • Steps for new deployment
          • Steps for production environments
        • Configuring security keyspaces
        • Setting up Kerberos
          • Kerberos guidelines
          • Enabling JCE Unlimited
            • Removing AES-256
          • Preparing DSE nodes for Kerberos
            • DNS and NTP
            • krb5.conf
            • Principal
            • Keytab
        • Enabling authentication and authorization
          • Defining a Kerberos scheme
          • Defining an LDAP scheme
        • Configuring JMX authentication
        • Configuring cache settings
        • Securing schema information
      • Managing database access
        • About RBAC
        • Setting up logins and users
          • Adding a superuser login
          • Adding database users
          • LDAP users and groups
            • LDAP logins
            • LDAP groups
          • Kerberos principal logins
          • Setting up roles for applications
          • Binding a role to an authentication scheme
        • Assigning permissions
          • Database object permissions
            • Data resources
            • Functions and aggregate resources
            • Search indexes
            • Roles
            • Proxy login and execute
            • Authentication schemes
            • DSE Utilities (MBeans)
            • Analytic applications
            • Remote procedure calls
          • Separation of duties
          • Keyspaces and tables
          • Row Level Access Control (RLAC)
          • Search index permissions
          • DataStax Graph keyspace
          • Spark application permissions
          • DataStax Studio permissions
          • Remote procedure calls
          • DSE client-tool spark
          • JMX MBean permissions
          • Deny (denylist) db object permission
          • Restricting access to data
      • Providing credentials from DSE tools
        • About clients
        • Internal and LDAP authentication
          • Command line
          • File
          • Environment variables
          • Using CQLSH
        • Kerberos
          • JAAS configuration file location
          • Keytab
          • Ticket Cache
          • Spark jobs
          • SSTableLoader
          • Graph and gremlin-console
          • dsetool
          • CQLSH
        • Nodetool
        • JConsole
    • Auditing database activity
      • Enabling database auditing
      • Capturing DSE Search HTTP requests
      • Log formats
      • View events from DSE audit table
    • Transparent data encryption
      • About Transparent Data Encryption
      • Configuring local encryption
        • Setting up local encryption keys
        • Encrypting configuration file properties
        • Encrypting system resources
        • Encrypting tables
        • Rekeying existing data
        • Using tools with TDE-encrypted SSTables
        • Troubleshooting encryption key errors
      • Configuring KMIP encryption
      • Encrypting Search indexes
        • Encrypting new Search indexes
        • Encrypting existing Search indexes
        • Tuning encrypted Search indexes
      • Migrating encrypted tables from earlier versions
      • Bulk loading data between TDE-enabled clusters
    • Configuring SSL
      • Steps for configuring SSL
      • Creating SSL certificates, keystores, and truststores
        • Remote keystore provider
        • Local keystore files
      • Securing node-to-node connections
      • Securing client-to-node connections
        • Configuring JMX on the server side
        • nodetool, nodesync, dsetool, and Advanced Replication
        • JConsole (JMX)
        • SSTableloader
        • Connecting to SSL-enabled nodes using cqlsh
      • Enabling SSL encryption for DSEFS
      • Reference: SSL instruction variables
    • Securing Spark connections
  • DataStax Enterprise 6.8 Security Guide
  • Authentication and authorization
  • Configuring authentication and authorization
  • Configuring JMX authentication

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 MBean server. 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 JConsole.

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.

Default settings

Locate the cassandra-env.sh file. The location of this file depends on the type of installation:

  • Package installations: /etc/dse/cassandra/cassandra-env.sh

  • Tarball installations: <installation_location>/resources/cassandra/conf/cassandra-env.sh

By default, JMX remote connections are disabled and JMX security authentication is disabled for both local and remote connections in the cassandra-env.sh file:

JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.authenticate=false"

Enabling DSE Unified Authentication

DSE provides unified authentication from utilities such as dsetool and 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.

Prerequisites

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.

Procedure

  1. On DSE nodes for which you want to allow access, set the JMX remote authenticate to true for remote or local, or both:

    JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.authenticate=true"

    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.

  2. 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"
  3. 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"
  4. Restart DSE.

Enabling JMX Native Authentication

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 nodetool or nodesync. When enabled, ensure that DSE Unified Authentication is disabled.

Generally, JMX settings are inserted into the cassandra-env.sh file. However, you can also specify them on the command line:

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

Procedure

  1. Locate the cassandra-env.sh file. The location of this file depends on the type of installation:

    • Package installations: /etc/dse/cassandra/cassandra-env.sh

    • Tarball installations: <installation_location>/resources/cassandra/conf/cassandra-env.sh

  2. If it does not already exist, create the /etc/cassandra directory from an account with sudo privilege.

    sudo mkdir /etc/cassandra
  3. Set the JMX remote authenticate to true for remote or local, or both:

    JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.authenticate=true"

    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.

  4. On DSE nodes where you want to disable JMX remote access, ensure jmxremote.authenticate is set to false:

    JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.authenticate=false"
  5. Uncomment the java.rmi.server.hostname setting, and change it to the IP address of the node to which you are connected. Example:

    JVM_OPTS="$JVM_OPTS -Djava.rmi.server.hostname=10.0.100.100"
  6. On nodes that allow access, set the path to the credentials file:

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

    Ensure that the path is accessible to the user who runs as cassandra.

  7. Create a jmxremote.password file that contains a user name and password on each line and save it to the location entered in the previous step. Example:

    touch jmxremote.password
    cassandra p4ssw0rd
  8. Change the ownership and permission of the jmxremote.password file. Example:

    chown cassandra:cassandra /etc/cassandra/jmxremote.password
    chmod 400 /etc/cassandra/jmxremote.password
  9. Optional: To limit the types of actions a user can perform, create a jmxremote.access file, uncomment the remote access option, and specify the path in the following setting:

    JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.access.file=/etc/cassandra/jmxremote.access"
  10. If you enabled the remote access in this step, edit the jmxremote.access file to include users and their proper permission level. Example:

    cassandra readwrite
    <<new_superuser>> readwrite
    <<some_other_user>> readonly

    The default superuser account is a security hazard! This account is used only for the purposes of illustration.

    The readonly permission allows the JMX client to read an MBean’s attributes and receive notifications. The readwrite permission 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.access file 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 cassandra is run by the default user cassandra.

  11. If all nodes on the cluster were updated, perform a rolling restart; otherwise restart only the affected nodes.

  12. Verify that authentication is working by running a nodetool command 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
  13. Repeat the configuration on each node in the cluster.

Defining an LDAP scheme Configuring cache settings

General Inquiries: +1 (650) 389-6000 info@datastax.com

© DataStax | Privacy policy | Terms of use

DataStax, Titan, and TitanDB are registered trademarks of DataStax, Inc. and its subsidiaries in the United States and/or other countries.

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries.

Kubernetes is the registered trademark of the Linux Foundation.

landing_page landingpage