Secure connections to and from DataStax Studio

DataStax Studio includes a web browser client and a Studio server. Securing DataStax Studio requires protecting the browser client-to-Studio server connection, and the Studio server-to-database connection.

Database authentication

To access a database from a notebook, you must create a connection in DataStax Studio. In the connection settings, you provide the necessary authentication credentials for your database.

Only create connections to clusters that you use in your notebooks, and use authentication credentials with minimum required permissions for the operations included in your notebooks.

  • DSE

  • Astra

Authentication of Studio connections to your DSE cluster depends on the cluster’s security configuration.

datastax studio to enterprise

To require authentication for Studio connections to DSE, do the following on your DSE cluster:

Then, set the authentication credentials in your Studio connection settings.

For Astra DB connections, authentication and authorization are handled through Astra application tokens and Secure Connect Bundles (SCBs).

SSL encryption

Client-to-node encryption protects in-flight data from client machines to a database cluster using SSL. It establishes a secure channel between the client and the coordinator node.

  • DSE

  • Astra

To use SSL-encryption for DSE connections, do the following:

  1. Enable SSL on your DSE cluster.

  2. Prepare the certificates.

    DataStax recommends using certificates signed by a CA. The truststore or CA certificate can be shared between all DSE servers and clients.

    For DataStax Studio, the public key certificate from the CA must be stored in a local truststore file. If two-way SSL is not configured, then the Studio connection only requires a truststore file. If two-way SSL is configured, then the Studio connection requires a truststore file and an appropriate keystore file.

    DataStax Studio only works with Java 8 .jks keystores and truststores.

    To perform server verification, the client needs to have the public key certificate of each node in the cluster stored in a local truststore file. This truststore file is password protected.

  3. In DataStax Studio, create or edit a connection.

    DSE connections use the Standard Connection type.

  4. Enter the basic connection details:

    • Name: Name of the connection, such as DSE Notebook Connection

    • Host/IP (comma delimited): The host names or IP addresses of the DSE cluster to connect to, such as 127.0.0.1. All hosts must be in a single datacenter. Default: localhost.

    • Username and Password: DSE cluster authentication credentials.

    • Port: IP connection port where the CQL native transport listens for clients. The default is 9042. This port must be the same as the native_transport_port in your DSE cluster’s cassandra.yaml file.

  5. To configure the encrypted connection, select Use SSL, and then configure the Truststore and Keystore settings as appropriate for your environment. Enter the local file path and password for the truststore file and, if required, the keystore file.

  6. Click Test to verify the connection.

  7. Click Save.

When connecting to Astra DB from DataStax Studio, SSL encryption is handled automatically through the database’s Secure Connect Bundle (SCB).

Ports

Studio uses the following ports by default when connecting to DSE clusters. If your cluster uses different ports, you must set the ports accordingly in Studio’s connection settings or configuration.yaml file.

  • CQL native transport: 9042

    Set this port when you create a connection to a DSE cluster. It must match the native_transport_port in your DSE cluster’s cassandra.yaml file.

    This setting isn’t configurable for Astra DB connections.

  • Thrift/Spark SQL: 10000

    For DSE clusters running AlwaysOn SQL (AOSS), set the defaultSparkSQLPort in Studio’s configuration.yaml file to the same value as the thrift_port in your cluster’s dse.yaml file.

    This setting doesn’t apply to Astra DB connections.

  • Graph: 8182

    The port on a DSE node running a Gremlin Server. For information about setting this port, see defaultGremlinPort in Studio’s configuration.yaml file.

DataStax recommends securing DSE ports in compliance with your security requirements.

Security best practices for distributed deployments

DataStax Studio doesn’t provide a multi-user experience, which means that any user that has access to your Studio instance can use any connection or notebook associated with that instance. When granting any application access to your databases, follow industry standard security best practices to help reduce security risks.

Because DataStax Studio is designed to be a local desktop application, distributed deployment introduces potential security risks. Namely, changing the httpBindAddress from localhost can expose your Studio instance to users on external machines. By extension, these users can access to your Studio notebooks and access the data in your connected clusters.

Here are some best practices for securing DataStax Studio, particularly if you need to share your DataStax Studio instance with multiple users over remote connections:

Use VPNs and firewalls to protect remote access gateways

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 authorized users can remotely access the DataStax Studio machine. The remote desktop gateway 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, and by using HTTPS for the Studio browser client.

If you need to set the httpBindAddress to anything other than localhost, use NGINX as an authentication proxy in front of DataStax Studio to authenticate users to the DataStax Studio browser client. Then, restrict the DataStax Studio browser client port to the local network with firewall rules. Only open the authentication-protected NGINX port to the outside network.

Finally, ensure that HTTPS is enabled between the browser client and the Studio server.

Restrict User Access

For all Studio installations, only grant access to users who need it:

  • Users who need to see and edit the Studio notebooks.

  • Users who have permissions to access the databases connected to that Studio instance.

Was this helpful?

Give Feedback

How can we improve the documentation?

© 2025 DataStax, an IBM Company | Privacy policy | Terms of use | Manage Privacy Choices

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, info@datastax.com