Advanced security options

Hiding error stacks

By default, the Dataiku DSS backend sends backend error stacks to logged-in users. This makes debugging and understanding easier.

This behavior can be disabled in the following way:

• Stop Dataiku DSS

DATADIR/bin/dss stop

• Edit the DATADIR/config/general-settings.json file

• Locate the "security" top-level key in the JSON file. If it does not exist, create it as an empty JSON object

• Within “security”, add or edit the following key : "hideErrorStacks" : true

• Start Dataiku DSS

DATADIR/bin/dss start

Hiding version info

By default, the Dataiku DSS backend sends Dataiku DSS version information, even to non-logged in users.

This behavior can be disabled in the following way:

• Stop Dataiku DSS

DATADIR/bin/dss stop

• Edit the DATADIR/config/general-settings.json file

• Locate the "security" top-level key in the JSON file. If it does not exist, create it as an empty JSON object

• Within “security”, add or edit the following key : "hideVersionStringsWhenNotLogged" : true

• Start Dataiku DSS

DATADIR/bin/dss start

Using secure cookies

By default, Dataiku DSS login cookies do not carry the Secure flag (which would make them unusable over non-secured HTTP connections).

If you configure Dataiku DSS to using HTTPS for all users, either natively or through a reverse proxy, you can enable the use of secure cookies. This further secures user connections by ensuring the browser never sends the session cookie over unsecured connections.

• Stop Dataiku DSS

DATADIR/bin/dss stop

• Edit the DATADIR/config/general-settings.json file

• Locate the "security" top-level key in the JSON file. If it does not exist, create it as an empty JSON object

• Within “security”, add or edit the following key : "secureCookies" : true

• Start Dataiku DSS

DATADIR/bin/dss start

Expiring sessions

You can configure Dataiku DSS to have sessions expire after a certain amount of time since login, and/or after a certain amount of inactivity.

Warning

• Sessions expiration can cause lost work: if you have work open and your session expires, you may not be able to save your work

• If you have a Jupyter notebook open and your session expires, the underlying Jupyter kernel remains alive and you can still communicate with it and execute code, until the next page refresh. However, saving updates to the notebook becomes impossible

• In Dataiku DSS, go to Administration > Settings > Security & Audit > User login & provisioning > Session management

• Set the “Maximum session duration” and “Idle timeout” options to the desired expiration timeout, respectively since login and inactivity.

• Save (restart is not needed)

Forcing a single session per user

By default, Dataiku DSS users can log in from multiple sessions at once. You can additionally configure Dataiku DSS to only allow a single session. When a user logs in, all their other sessions are terminated.

• In Dataiku DSS, go to Administration > Settings > Security & Audit > User login & provisioning > Session management

• Check the “Force single session per user” option to enable it

• Save (restart is not needed)

Restricting visibility of groups and users

By default, all logged-in Dataiku DSS users can view the list of groups and users. This is useful for:

• Allowing project owners to add groups to their projects

• Allowing users to mention all users

You can select to restrict visibility of groups and users. The following rules apply:

• If you are admin, you can see everything

• You can see all groups to which you belong

• You can see all users of groups to which you belong

• In addition, you can see all users that are participants in projects in which you are participant

Instructions:

• Stop Dataiku DSS

DATADIR/bin/dss stop

• Edit the DATADIR/config/general-settings.json file

• Locate the "security" top-level key in the JSON file. If it does not exist, create it as an empty JSON object

• Within “security”, add or edit the following key : "restrictUsersAndGroupsVisibility" : true

• Start Dataiku DSS

DATADIR/bin/dss start

Note

This is a best-effort feature. Obvious listing of users are suppressed, but we do not guarantee perfect isolation.

Redirecting to a custom URL after logout

By default, when users log out from Dataiku DSS, they are redirected to a standard Web page hosted by Dataiku DSS.

To configure Dataiku DSS to redirect users to a different URL when they log out:

• Stop Dataiku DSS

DATADIR/bin/dss stop

• Edit the DATADIR/config/general-settings.json file

• Locate the "security" top-level key in the JSON file. If it does not exist, create it as an empty JSON object

Note

If you edit this file manually, ensure that each key appears only once in general-settings.json.

• Within "security", set "postLogoutCustomURL" to the target URL.

Use CUSTOM_URL to redirect with a GET request:

"postLogoutBehavior": "CUSTOM_URL",
"postLogoutCustomURL": "https:///my-custom-url"

Use CUSTOM_URL_POST to send a POST request:

"postLogoutBehavior": "CUSTOM_URL_POST",
"postLogoutCustomURL": "https:///my-custom-url"

When postLogoutBehavior is set to CUSTOM_URL_POST, Dataiku DSS sends a POST request to postLogoutCustomURL with the post_logout_redirect_uri parameter set to the Dataiku DSS logged-out page. When Dataiku DSS uses OpenID Connect SSO and a client ID is configured, the request also includes client_id to align with the OpenID Connect RP-Initiated Logout specification.

Only http and https URLs are accepted for postLogoutCustomURL.

Supported values for postLogoutBehavior are CUSTOM_URL and CUSTOM_URL_POST.

If postLogoutBehavior is set to CUSTOM_URL or CUSTOM_URL_POST, postLogoutCustomURL is required.

Dataiku DSS validates these settings when saving the configuration and when loading it. Invalid values are rejected and Dataiku DSS falls back to the default behavior and redirects users to the Dataiku DSS logged-out page.

• Start Dataiku DSS

DATADIR/bin/dss start

Example general-settings.json file

With the previous options enabled, your general-settings.json could look like:

{
  "udr": true,
  "proxySettings": {
    "port": 0
  },
  "mailSettings": {},
  "maxRunningActivitiesPerJob": 5,
  "maxRunningActivities": 5,
  "ldapSettings": {
    "enabled": false,
    "useTls": false,
    "userFilter": "(\u0026(objectClass\u003dposixAccount)(uid\u003d{USERNAME}))",
    "displayNameAttribute": "cn",
    "emailAttribute": "mail",
    "enableGroups": true,
    "groupFilter": "(\u0026(objectClass\u003dposixGroup)(memberUid\u003d{USERNAME}))",
    "groupNameAttribute": "cn",
    "autoImportUsers": true
  },
  "computablesAvailabilityMode": "EXPOSED_ONLY",
  "globalCrossProjectBuildBehaviour": "STOP_AT_BOUNDARIES",
  "noLoginMode": false,
  "security" : {
    "hideVersionStringsWhenNotLogged" : true,
    "hideErrorStacks" : true,
    "secureCookies" : true,
    "restrictUsersAndGroupsVisibility": true,
    "postLogoutBehavior": "CUSTOM_URL",
    "postLogoutCustomURL": "https://www.dataiku.com"
  }
}

Restricting types of files that can be uploaded in wikis

By default, all logged-in Dataiku DSS users can upload any type of files to wiki articles.

You can configure Dataiku DSS to restrict the types of files that are allowed by specifying a list of accepted extensions.

• Edit the DATADIR/config/dip.properties file

• Add dku.wikis.authorizedUploadExtensions=png,jpg,jpeg,gif,txt,csv (update the list according to your security needs)

Restricting exports

It is possible to globally restrict some export features in Dataiku DSS (regardless of project permissions).

Warning

Any restriction to exports conceptually remains a “best-effort”. Any user who is granted the right to see data in Dataiku DSS can, with more or less effort, manage to export it, if only by copy/pasting it.

To use these options, a Dataiku DSS administrator with access to the Dataiku DSS server needs to edit the “config/dip.properties” file in the Dataiku DSS data dir and add one of the following lines:

• dku.exports.disableAllDatasetExports=true

  • Disables exports of datasets globally on the instance (the exports that are restricted are the ones that are about “Download” of datasets in order to generate data files (CSV, Excel, Tableau Hyper, …).

  • Other exports (ML data, schema, SQL queries, prepared data) remain possible

  • Disables ability to include datasets in project exports and bundle downloads

  • Disables ability to attach datasets to emails in scenarios

• dku.exports.disableAllDataExports=true (implies the previous one)

  • Disables exports of datasets globally on the instance (the exports that are restricted are the ones that are about “Download” of datasets in order to generate data files (CSV, Excel, Tableau Hyper, …).

  • Disables exports of prepared data or SQL query results

  • Exports of ML data and schemas remain possible

  • Disables ability to download files of zips from managed folders

  • Disables ability to include datasets or managed folders in project exports and bundle downloads

  • Disables ability to attach datasets or other data items to emails in scenarios

• dku.exports.disableAllExports=true (implies the previous one)

  • Disables exports of datasets globally on the instance (the exports that are restricted are the ones that are about “Download” of datasets in order to generate data files (CSV, Excel, Tableau Hyper, …).

  • Disables exports of prepared data or SQL query results

  • Disables exports of ML data and schemas

  • Disables ability to download files of zips from managed folders

  • Disables ability to include datasets or managed folders in project exports and bundle downloads

  • Disables ability to attach datasets or other data items to emails in scenarios

• dku.exports.disableCopySampleToClipboard=true

  • Disables the ability to copy samples to the clipboard. This option enable/disable the feature everywhere, with the exception of SQL notebook (defaults to false, i.e. enabled)

• dku.exports.disableSQLNotebookCopyResultToClipboard=true

  • Disables the ability to copy samples to the clipboard on SQL notebook (defaults to false, i.e. enabled)

Setting security-related HTTP headers

It is possible to set the following security-related HTTP headers:

• X-Frame-Options

• Content-Security-Policy

• X-XSS-Protection

• X-Content-Type-Options

• Strict-Transport-Security

• Referrer-Policy

• Permissions-Policy

• Cross-Origin-Embedder-Policy

• Cross-Origin-Opener-Policy

• Cross-Origin-Resource-Policy

All of these are configured in the [server] section of the install.ini file.

Here is a syntax example:

[server]
port=11000

content-security-policy=script-src 'self' 'unsafe-inline' 'unsafe-eval'; frame-ancestors 'none'
x-frame-options=SAMEORIGIN
x-content-type-options=nosniff
x-xss-protection=1;mode=block
hsts-max-age=31536000
referrer-policy=same-origin
permissions-policy=fullscreen
cross-origin-embedder-policy=unsafe-none
cross-origin-opener-policy=unsafe-none
cross-origin-resource-policy=cross-origin

You need to run ./bin/dssadmin regenerate-config and to restart Dataiku DSS after changing this.

Allowing Dataiku DSS to be hosted inside an iframe

By default, Dataiku DSS cannot be hosted inside an iframe as Web browsers treats its authentication cookies as SameSite=Lax.

To configure Dataiku DSS to emit authentication cookies using SameSite=None:

• Stop Dataiku DSS

DATADIR/bin/dss stop

• Edit the DATADIR/config/general-settings.json file

• Locate the "security" top-level key in the JSON file. If it does not exist, create it as an empty JSON object

• Within “security”, add or edit the following keys: "sameSiteNoneCookies" : true and "secureCookies" : true

• Start Dataiku DSS

DATADIR/bin/dss start

Note

Dataiku DSS must be accessed via the HTTPS protocol and cookies must be set as Secure for this option to work as Web browsers do not take into account the SameSite cookie parameter for non-secure cookies.

Preventing links to be clickable in data tables

By default, links are displayed in dataset Explore and dataset insights.

To prevent this, edit the DATADIR/config/dip.properties file and add the following key: dku.feature.dataTableLinks.enabled=false

Allowing Dataiku DSS users to edit their display names and emails

Starting from version 13.2.0, users can no longer edit their display names and email addresses. Only Dataiku DSS administrators have the ability to make these changes. This restriction helps prevent impersonation by Dataiku DSS users.

To allow users to update their display names and email addresses:

• Stop Dataiku DSS

DATADIR/bin/dss stop

• Edit the DATADIR/config/general-settings.json file

• Locate the "security" top-level key in the JSON file. If it does not exist, create it as an empty JSON object

• Within “security”, add or edit the following keys: "enableEmailAndDisplayNameModification" : true.

• Start Dataiku DSS

DATADIR/bin/dss start

Note

Please note that enabling email and display name modifications will disable the ability for users to share assets, such as projects, via email invitations.