Connections security

Securing access to connections

It is possible to restrict access to connections. If access to a DSS connection is restricted, only members of selected groups may “freely use” this connection.

This can be configured in the settings of each individual connection.

“Freely using” a connection means being able to:

  • Create new datasets on the connection

  • Modify the settings of a dataset using the connection

  • Browse in any way the connection

  • Send code (like SQL) which may be used indirectly to browse in any way the connection.

Note that this does NOT restrict the ability to read datasets which have already been defined on a connection.

For example, with a SQL database, you may want a few people to be able to create datasets based on specific tables of the connection, and then have a larger group of analysts using this data, but who are not allowed to read other tables in this database.

In that configuration, you would have the small group being granted the “freely use” permission on the database connection, create the datasets in a project, and grant read/write access to the project to the larger group. The analysts are able to read the data, but cannot access other tables from the database in any way.

Note that access to a connection can only be granted to a group. Thus, it cannot be granted to a non-personal API key (since these API keys do not belong to groups). In order to access connections (using the rules described above) with an API key, you will need to use either:

  • An admin API key

  • Or a personal API key

Reading details of a connection

By default, even if a user may “freely use” a connection, he may not read the details of the connection.

The details of the connection include:

  • The path (for filesystem-connection)

  • The HDFS properties (for HDFS connections)

  • The hostname / database / … (for SQL connections)

  • The credentials (for all connections which include a credential)

In the settings page of the connection, an administrator may grant the right to some groups to read the details of a connection. The details can only be read using code, as no part in the UI will show it.

Note

Granting “Details readable by” on a connection to a group gives users access to the unencrypted credential for this connection. Make sure that you wish this.

Beware that for Hadoop filesystem datasets that actually point to S3, WASB, …, the details of the HDFS connection usually contain a secret credential in order to connect to the cloud storage.

Note

Granting “Details readable by” on HDFS and S3 connections is strongly recommended in order to obtain good performance in Spark. If Spark processes do not have the “Details readable by” permission, they are forced into a slow path that very strongly degrades performance of Spark jobs.

For more information, see Interacting with DSS datasets

Note that access to a connection can only be granted to a group. Thus, it cannot be granted to a non-personal API key (since these API keys do not belong to groups). In order to access connections (using the rules described above) with an API key, you will need to use either:

  • An admin API key

  • Or a personal API key

Per-user credentials for connections

Note

While this feature is distinct from the User Isolation Framework feature, it is only available for DSS licenses where the User Isolation Framework is enabled.

For DSS connections which require credentials (most SQL connections, MongoDB, FTP, …), the administrator can configure the connection so that instead of having a global service credential, each user can enter his personal credentials. Each action on the database performed by this user will use his personal credential.

User credentials are stored encrypted, but since DSS needs to send them to the external systems, DSS administrators are technically able to decrypt these credentials.

To configure a connection with per-user credentials:

  • Go to Administration > Connections and select the connection

  • In “Connections credentials”, select “Per-user”

  • Save the connection

Users can then enter their personal credentials by going to their Profile > Credentials.

Note that in this mode, there is no global credential at all anymore. Thus, it is not possible to test a connection immediately, because no credentials available. The proper initialization sequence for a new connection is thus:

  • The admin enters connection details, but no credentials, and enables per-user credentials

  • The admin saves the new connection

  • The admin goes to his profile and enters his credentials

  • The admin can then go back to the connection’s page and test the connection

Personal connections

You can grant to user groups the permission to create their own connections. Connections are normally only created by the DSS administrator. By granting this “personal connection” permission, end users can create their own connections.

This feature is only available for connections for which a credential is required (most SQL connections, MongoDB, FTP, …). The connection can only be “freely used” by its creator (see beginning of this section).