DataStax Studio security best practices

Best security practices for deploying DataStax Studio.

cassandra.yaml

The location of the cassandra.yaml file depends on the type of installation:

Package installations	/etc/dse/cassandra/cassandra.yaml
Tarball installations	`installation_location`/resources/cassandra/conf/cassandra.yaml

dse.yaml

The location of the dse.yaml file depends on the type of installation:

Package installations	/etc/dse/dse.yaml
Tarball installations	`installation_location`/resources/dse/conf/dse.yaml

DataStax Studio does not provide a multi-user experience, which means that any user that has access to the Studio instance can use any connection or notebook associated with that instance. As for any application that has access to the database, security best practices prevent potential security risks.

Restrict user access

For all Studio installations, grant access only to:

Users who need to see and edit the Studio notebooks
Users who have the right to access the database connections associated with that Studio instance

Secure ports

The default DSE ports that Studio uses:

CQL - port 9042
The port where the CQL native transport listens for clients. Configure the CQL port when you create a connection to a DSE cluster. The port value in the connection needs to match the port value specified for native_transport_port in the cassandra.yaml file.
Spark SQL (AOSS) - port 10000
The Thrift port on a DSE node running AlwaysOn SQL (AOSS). The defaultSparkSQLPort port value in the configuration.yaml Studio configuration file needs to match the port value specified for thrift_port in the dse.yaml file.
Graph - port 8182
The port on a DSE node running Gremlin Server. The defaultGremlinPort port value in the configuration.yaml Studio configuration file needs to match the port value specified for gremlin_server in the dse.yaml file.

Tip: DataStax recommends securing ports in compliance with your security requirements.

Ensure that Studio configuration reflects any port changes on the DSE cluster.

When centrally deploying DataStax Studio, deploy all Studio instances behind a VPN.

Architecture

Secure a centrally deployed instance of DataStax Studio behind a firewall, accessible only through a bastion node. This architecture assumes that only users that have been granted access can remote desktop to the DataStax Studio machine. The remote desktop enables privileged users to access the Studio browser client using localhost as its bind address.

Use an authentication proxy

Enable and protect Studio server access by using:

An authentication proxy to access the Studio browser client
HTTPS for the Studio browser client

Bind address

Because DataStax Studio is designed to be a local desktop application, a warning in configuration.yaml describes the risks of changing the bind address configuration from localhost.

Warning: Changing the setting from the default (localhost) can pose a security risk as other users on external machines can gain access to notebooks and the DSE clusters to which those notebooks are connected.

Authentication proxy

If the bind address must be changed from localhost, use NGINX as an authentication proxy in front of DataStax Studio to authenticate users to the DataStax Studio browser client. This solution integrates with LDAP and has been tested by NGINX against OpenLDAP and Microsoft Windows Server Active Directory versions 2003 and 2012. This option is available as open-source or paid subscription.

In this model, restrict the DataStax Studio browser client port to the local network with firewall rules and open only the authentication-protected NGINX port to the outside network. This solution combined with enabling HTTPS between the browser client and Studio server help secure this deployment model.

Secure connections

See Securing connections from DataStax Studio to DataStax Enterprise.