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
- 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.
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
- 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.
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.