DataStax Studio security best practices

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 to only:

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

Configuration File Locations

Configuration File Locations
Filename Location dependent upon type of installation


  • Package installations: /etc/dse/dse.yaml

  • Tarball installations: <installation_location>/resources/dse/conf/dse.yaml


  • Package installations: /etc/dse/cassandra/cassandra.yaml

  • Tarball installations: <installation_location>/resources/cassandra/conf/cassandra.yaml

Secure Ports

The default DSE ports that Studio uses:

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.


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.

DataStax Studio architecture

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.

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.

Was this helpful?

Give Feedback

How can we improve the documentation?

© 2024 DataStax | Privacy policy | Terms of use

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.

General Inquiries: +1 (650) 389-6000,