Main project permissions¶

DSS uses a groups-based model to allow users to perform actions through it.

The basic principle is that users are added to groups, and groups have permissions on each project.

Per-project group permissions ¶

On each project, you can configure an arbitrary number of groups who have access to this project. Adding permissions to projects is done in the Permissions pane of the Security menu.

Each group can have one or several of the following permissions. By default, groups don’t have any kind of access to a project.

Admin ¶

This group may perform any action on the project, including:

change the permissions and owner of the project
create project bundles

This permission implies all other permissions.

Read project content ¶

This group may see the Flow, access the datasets, read the recipes, … More generally speaking, this group may read every configuration and data in this project.

This permission implies the “Read dashboards” permission

Write project content ¶

This group may read and write every configuration and data in this project. This includes the ability to create new datasets, recipes, …

This also includes the ability to run all jobs in this project.

Note

This permission is the “default” permission that you may want to give to your data team.

This permission implies the “Read project content”, “Read dashboards”, “Run scenarios” and “Write dashboards” permissions

Export datasets ¶

This group may click on the “Download” button to retrieve the content of a dataset.

Warning

Disabling this permission removes the most obvious way to download whole datasets, but through various means, users who have at least “Read project content” will still be able to download datasets.

If you absolutely want your users not to be able to retrieve the full content of datasets, do not give them access to the project.

Run scenarios ¶

This group may run scenarios. They may not run jobs that are not part of a scenario. Only scenarios that have a “Run As” user may be run by users who only have this permission.

This permission is generally not very useful without the “Read project content” permission.

This group may read dashboards that have been created. They may not modify anything. They can only read dashboard insights that use project objects that have been shared with them using Workspaces & dashboards authorizations.

Write dashboards ¶

This group may create their own dashboards, using the project objects that have been shared with them using Workspaces & dashboards authorizations.

This permission implies “Read dashboards”.

Manage authorized objects ¶

This group may modify which objects of the project are usable by dashboard-only users through the Workspaces & dashboards authorizations and accessible through a workspace.

This permission is generally not very useful without the “Read project content” permission. This permission is implied by the “Share to workspaces” permission.

The main use case for this permission is the following:

A group of analysts and data scientists creates a Flow
The data is of medium sensitivity so all dashboard users could use any of the Flow
However, the dashboard users must not be able to break or modify the Flow
Thus, the dashboard users (or a subgroup of them) has this permission to gain access to source datasets

Manage shared objects ¶

This group may modify which objects of the project are available in other projects through the Shared objects.

This permission is generally not very useful without the “Read project content” permission.

The main use case for this permission is the following:

A group of analysts and data scientists creates a Flow
The data is of medium sensitivity so all or some DSS users should be able to reuse it on other projects
However, the other projects’ users must not be able to break or modify the Flow
Thus, a group of other project’s users has permission to go in the project, and “pick” datasets to use in other projects.

Execute app ¶

This permission is only exposed on projects converted into a Dataiku application or an application-as-recipe.

This group may execute the corresponding application if the application is configured to be instantiated only by user with this permission. Else this permission is not needed.

Project owner ¶

In addition to the per-group access, each project has a single user who “owns” the project. Being the owner of a project does not grant any additional permissions compared to being in a group who has Administrator access to this project.

This owner status is used mainly to actually grant access to a project to the user who just created it.

Project visibility ¶

It is possible to allow all users to access a project’s page displaying a limited amount of information about the project regardless of the users’ permissions. The information displayed in this case includes the project image, name, short description, owner, tags and status.

This feature can be enabled on a per-project basis or for all projects on the DSS instance on the Administration > Settings > Misc page. Discoverable projects appear in the Projects and Project Folders view, in the Catalog, and in the Search DSS results for all users making them easily discoverable. If a user doesn’t have access to a discoverable project, the project is denoted with a padlock symbol.

Per-project single user permissions ¶

In addition to the per-group access, on each project, you can configure an arbitrary number of individual users who have access to this project. Adding permissions to projects is done in the Permissions pane of the Security menu.

Each user can be granted the same kind of project permissions than groups above. This is useful for a non-administrator to give access to a project to some users individually, without the need for those users to belong to specific groups.

Warning

When using User Isolation in “DSS-managed ACL” mode, HDFS ACLs are not supported for individual user permissions on projects. See Hadoop Impersonation (HDFS, YARN, Hive, Impala).

Global group permissions ¶

In addition to the per-project permissions, groups can also be granted several global permissions that apply to all DSS.

These permissions are configured in the settings screen of the group.

Administrator: members of a group with this permission can perform any action on DSS. DSS administrators are implicitly administrators of all DSS projects and may access any project, even without explicitly being granted access through a project-group grant.

Projects creation ¶

Create projects: members of a group with this permission can create their own projects, using a blank project, project duplication of project import
Create projects using macros: members of a group with this permission can create projects using a project creation macro
Create projects using templates: members of a group with this permission can create projects using predefined templates (Dataiku samples and tutorials)
“Write in root project folder”: members of a group with this permission can create folders and projects in the root folder, or move them to the root.

Workspaces ¶

Create workspaces: members of a group with this permission can create their own workspaces.
Share to workspaces: members of a group with this permission can share objects to workspaces.

Code execution ¶

“Write isolated code”: members of a group with this permission can write code which will run with impersonated rights. This permission is only available when User Isolation Framework is enabled.
“Write unisolated code”: members of a group with this permission can write code which will be executed with the UNIX privileges of the DSS UNIX user.
“Create active Web content”: members of a group with this permission can author Web content that is able to execute Javascript when viewed by other users. This includes webapps, Jupyter notebooks and RMarkdown reports

Code envs & Dynamic clusters ¶

“Manage all/own code envs”: members of a group with this permission can create and manage code environments; their own, those they’ve been given administrative access to, and even others, if given the ‘all’ permission.
“Manage all/own clusters”: members of a group with this permission can create and manage clusters; their own, those they’ve been given administrative access to, and even others, if given the ‘all’ permission.

Advanced permissions ¶

“Develop plugins”: members of a group with this permission can create and edit development plugins. Be aware that this permission could allow a hostile user to circumvent the permissions system.
“Edit lib folders”: members of a group with this permission can edit the Python & R libraries and the static web resources in the DSS instance.
“Create personal connections”: members of a group with this permission can create new connections to SQL, NoSQL, and Cloud storage.
“View indexed Hive connections”: members of a group with this permission can use the DSS catalog to view indexed Hive connections.
“Manage user-defined meanings”: members of a group with this permission can create instance-wide user-defined meanings, which will be accessible and usable by all DSS projects.
“Create published API services”: members of a group with this permission can create an API service endpoint and publish it to a DSS API node through the DSS API Deployer.

Write unisolated code: details ¶

For more information about enabling user isolation, see User Isolation Framework

Regular security mode¶

When UIF is disabled, DSS runs as a single UNIX user. All code which is written through the interface and executed locally is therefore ran with the permissions of this said user.

This includes notably:

Python and R recipes
Python and R notebooks
PySpark and SparkR recipes
Custom Python code in preparation recipes
Custom Python code for machine learning models

No user (even with the Data Scientist profile) may write such code if they are not granted the “Write unisolated code” permission.

It is important to note that since the DSS Unix user has filesystem access to the DSS configuration, a user who has the “write unisolated code” permission is able to alter the DSS configuration, including security-related controls. This means that a hostile user with these privileges would be able to bypass DSS authorization mechanisms.

User isolation enabled¶

When UIF is enabled, most of the aforementioned code runs with end-user permissions. The “write unisolated code” permission only applies to the following specific locations where the code is not ran using end-user impersonation:

Write custom partition dependency functions
Write Python UDF in data preparation

Multiple group membership ¶

Users may belong to several groups. All permissions are cumulative: being a member of a group who has a given permission grants it, even if you are also member of a group who doesn’t have said permission.

DSS does not have negative permissions.