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
| Filename | Location dependent upon type of installation |
|---|---|
|
|
|
|
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.yamlfile. -
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.yamlfile. -
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.yamlfile.
|
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.
|
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.
