User Groups & Permissions¶

Reference | Global vs. per-resource group permissions
Reference | Global group permissions
Reference | Per-resource group permissions
How-to | Set up user groups (overview)
Tip | Creating a permissions model based on user types
How-to | Create a group and assign it global permissions
How-to | Verify group membership and permissions
How-to | Grant per-project permissions
How-to | Control access to code environments
How-to | Control access to managed clusters
How-to | Assign access to containerized execution
How-to | Assign Deployer infrastructure permissions
Code Sample | Add a group to a Dataiku project using Python
FAQ | Which activities require that a user be added to the allowed_user_groups local Unix group?

Dataiku DSS (Dataiku) uses a groups-based model to allow users to perform actions through it. Users can belong to an arbitrary number of groups. Groups can have one or several permissions, which may be global or per-resource group permissions.

In this section, explore resources related to this topic.

Reference | Global vs. per-resource group permissions ¶

There are two types of group permissions: global and per-resource.

Note

All permissions are cumulative. Users in a group are granted all of the group permissions, even if they are also a member of a group that doesn’t have the same permissions. Dataiku does not have negative permissions.

Group permissions¶

A group is a configurable collection of users, such as administrators or data-team. Users can belong to an arbitrary number of groups for which their permissions become cumulative. The administrator assigns global permissions for each group. The administrator can choose to map permissions for a group locally or through LDAP.

Per-resource permissions¶

Once groups are configured, the administrator grants per-resource group permissions.

While groups have permissions at the instance level, the administrator can assign permissions to specific groups at the resource level.

Resources are elements where the administrator might want to manage security, including projects, code environments, managed clusters, containerized execution, and infrastructure elements of the Deployer.

Permissions are specific to a resource and differ between resource types. For example, whether or not a group can edit a project is configurable at the project level.

Per-resource group permissions include the following:

Projects: How to assign per-project permissions.
Code environments: How to limit who has access to a code environment.
Managed clusters: How to assign owner and group permissions to use, operate, and manage Kubernetes clusters running on the major cloud providers.
Containerized execution: How to restrict which user groups have the right to use a specific Kubernetes execution configuration.
Infrastructure elements of the Deployer: How to grant group permissions with certain privileges. In this section, we’ll show you how to grant group access with view, deploy, and admin permissions on the API deployer for Published API Services and Infrastructures.

Reference | Global group permissions ¶

Administrator¶
Permission	Description
Administrator	When you select Administrator, all other permissions are automatically selected, meaning members of this group can perform any action on Dataiku. Administrators also may access any project, even without explicitly being granted access to each one.

Projects creation¶
Permission	Description
Create projects	Allows users to create their own projects using a blank project, project duplication or project import.
Create projects using macros	Allows users to create projects using project creation macros, which are administrator-controlled code.
Create projects using templates	Allows users to create projects using predefined templates from Dataiku samples and tutorials.
Write in root project folder	Allows users to create folders and projects in the root folder, or move them to the root.

Workspaces¶
Permission	Description
Create workspaces	Allows users to create their own workspaces.
Share to workspaces	Allows users to share project objects to workspaces.

Code execution¶
Permission	Description
Write isolated code	Allows users to write code that will run with impersonated rights. This permission is only available when User Isolation Framework is enabled. The framework is automatically managed for you when using Dataiku Cloud Stacks installation.
Write unisolated code	Allows users to run local code without impersonation isolation. Code will be executed with the UNIX privileges of the user.
Create active Web content	Allows users to author Web content, such as webapps, Jupyter notebooks and RMarkdown reports, that is able to execute JavasScript when viewed by other users.

Code envs & Dynamic clusters¶
Permission	Description
Manage all code envs	Allows users to create and manage code environments, including their own, those they’ve been given administrative access to, and others. If selected this will automatically also select “Create code envs.”
Create code envs	Allows users to create new code environments. Can be selected separately without giving access to manage all code envs.
Manage all clusters	Allows users to create and manage clusters, including their own, those they’ve been given administrative access to, and others. If selected this will automatically also select “Create clusters.”
Create clusters	Allows users to create new clusters. Can be selected separately without giving access to manage all clusters.

Advanced permissions¶
Permission	Description
Develop plugins	Allows users to create and edit development plugins. Be aware that this could allow a hostile user to circumvent the permissions system.
Edit lib folders	Allows users to edit the Python and R libraries and the static Web resources in the Dataiku instance.
Create personal connections	Allows users to create new connections to SQL, NoSQL, and cloud storage.
View indexed Hive connections	Allows users to view indexed Hive connections using the Dataiku catalog.
Manage user-defined meanings	Allows users to create instance-wide user-defined meanings, which will be accessible and usable by all projects.
Create published API services	Allows users to create an API service endpoint and publish it to a Dataiku API node through the Deployer.
Create published projects	Allows users to create and publish projects to a Dataiku Automation node through the Deployer.

Reference | Per-resource group permissions ¶

Project Permissions¶
Permission	Description	Note	Other permissions automatically granted
Admin	Allows group members to perform any action on the project, including: change the permissions and owner of the project and create project bundles.		All other permissions
Read project content	Allows group members to see the Flow, access the datasets, and read the recipes. More generally speaking, this group may read every configuration and data in this project.		Read dashboards
Write project content	Allows group members to read and write every configuration and dataset in this project. This includes the ability to create new datasets, recipes, and run all jobs in this project.	This permission should be the default for a data team working within a project.	Read project content Read dashboards Run scenarios Write dashboards
Share to workspaces	Allows group members to share objects (dashboards, datasets, wiki pages) to workspaces.	Instance admins must separately grant the group permission to share content into workspaces, regardless of source project.	Manage authorized objects
Export datasets	Allows group member to click on the “Download” button to retrieve the content of a dataset.	Disabling this permission removes the most obvious way to download whole datasets, but users who have at least Read project content permission will still be able to download datasets. If you do not want your users to be able to retrieve the full content of datasets, do not give them access to the project.
Read dashboards	Allows group members to 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 Dashboard authorizations.
Write dashboards	Allows group members to create their own dashboards, using the project objects that have been shared with them using Dashboard authorizations.		Read dashboards
Run scenarios	Allows group members to run scenarios. They may not run jobs that are not part of a scenario. Users with this permission may only run scenarios that have a “Run As” user.	This permission is generally not very useful without the Read project content permission.
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. 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 exposed elements	Allows group members to modify which objects of the project are available in other projects through the exposed 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 available 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 a user with this permission. Otherwise this permission is not needed.

Code Environment Permissions¶
Permission	Description
Use	Allows group members to use a code environment (for example in recipes and notebooks).
Update settings & packages	Allows group members to update settings and change included packages.
Admin	Allows group members to have full administrative control over the code environment.

Managed Cluster Permissions¶
Permission	Description
Use	Allows group members to select the cluster and use it in a project.
Change settings & Operate	Allows group members to modify cluster settings.
Admin	Allows group members to have full administrative control over clusters.

Infrastructure Permissions¶
Permission	Description
View	Allows group members to view existing deployments.
Deploy	Allows group members to create and update deployments.
Admin	Allows group members to have full administrative control over the deployment infrastructure (including managing the permissions).

How-to | Set up user groups (overview)¶

Setting up user groups is a three-step process:

Create a permission model based on user types
Create groups and assign permissions
Verify group membership and permissions

Completing these steps will help you understand the various permissions available and how to assign permissions to different groups.

Tip | Creating a permissions model based on user types ¶

Before setting up groups in the platform, you should work with relevant teams in your organization to identify the different end-user types. You should start with a small number of groups, around two to four.

When setting up your model, pay special attention to those permissions that create elements for other platform users, like projects, code environments and managed clusters. Those permissions should only be assigned to a small number of people to maintain a clear structure on the platform.

For example, an organization might have three user groups with the following access needs:

Administrators who configure and maintain the installation and need full access
Visual users who only need to view and share dashboards
Data scientists and analysts who need to create, complete and share projects using code

How-to | Create a group and assign it global permissions ¶

In this article we’ll look at default groups built into Dataiku. We’ll also create a new group and set custom global permissions.

Launch Dataiku¶

Log in to Fleet Manager.
From Instances, choose All and then locate the instance you want to manage.
Select Go to DSS.

Note

The instance must be provisioned and running.

View default groups¶

In your Dataiku instance, choose Administration from the Applications menu.
Navigate to the Security tab.
In the left panel, select Groups.

You should see the three default groups built into each Dataiku instance: administrators, data-team, and readers. You can select each group name to view its settings. This is also where you can change permissions for each group.

Notice the administrator’s group grants all permissions to those in the group, and the instance admin is included in this group by default.

Create a new group¶

Let’s say we wanted to create a new group with custom permissions. To do this:

Select +New Group in the top right.
Type a group name.
Enter a description.
Type should be Local.

Assign global permissions¶

Based on the permissions model within your organization, select the permissions you want to allow for this group.
Refer to the global permissions table to learn more about each permission option.
Click Save in the top right to save your changes.

How-to | Verify group membership and permissions ¶

You can verify group membership and permissions in one chart.

Go to Administration and select the Security tab.
In the left panel, choose Authorization Matrix.

Dataiku displays access permissions by user.

To view access permissions by group:

Select By group from the By user menu arrow.

The first table displays global permissions by group, and the second table displays project permissions by group.

../../_images/user-groups-authorization-matrix.png

How-to | Grant per-project permissions ¶

On each project, you can configure an arbitrary number of groups who have access to a particular project. In this section, we’ll show you how to configure any number of groups to have access to a project and then assign permissions to each group.

By default, groups don’t have any access to a project.

Note

While you can also control access to projects at the user level, Dataiku recommends using group settings as they are easier to manage.

Navigate to project security¶

Open a Dataiku project.
From the top navigation bar, go to Project Settings (the three vertical dots), and choose Security.
Choose Permissions from the left panel.

You should see a page that lists the project owner and shows that no group has access to this project.

Select groups¶

To grant access to a group:

Select the Select a group menu arrow, and then choose a group.
Select +Grant Access to Group.

Dataiku now shows the group you added, along with permission options. In this example, we have selected multiple groups.

Assign permissions¶

After you have defined which groups can access the project, you assign permissions.

To assign permissions:

Select the checkbox for each project permission you want to assign, and then save your changes.

How-to | Control access to code environments ¶

In this section, we’ll show you how to control who has the rights to manage and use a particular code environment.

Navigate to code environment permissions¶

From the top navigation bar, go to the Applications menu and choose Administration.
Navigate to the Code Envs tab.
Select a code environment.
Choose Permissions from the left panel.

Assign an owner¶

The owner owns the code environment and has all permissions by default.

To assign or transfer ownership:

Select the Owner menu arrow, and then choose a user.
If you are transferring ownership, select Confirm and then Save.

Limit which groups can view the code environment¶

By default, all Dataiku users on the instance can see the code environment and choose to use it. You can change this and choose to configure which groups can view the code environment.

To limit which groups can view the code environment:

Clear the Usable by all checkbox.
Select Save.

Now you are ready to select groups and assign permissions.

Select groups¶

Select the Select a Group menu arrow, and then choose a group.
Select +Grant Access to Group.
Repeat for each group you want to add.

Dataiku now shows the group you added, along with permission options.

Assign permissions¶

To assign permissions:

Select the checkbox for each permission you want to assign according to the per-resource permissions table, and then select Save to save your changes.

How-to | Control access to managed clusters ¶

DSS can automatically start, stop and manage Kubernetes clusters running on the major cloud providers. Each cluster has an owner and groups that are granted access levels. In this section, we’ll show you how to assign owner and group permissions to use, operate, and manage Kubernetes clusters running on the major cloud providers.

Navigate to cluster permissions¶

From the top navigation bar, go to the Applications menu and choose Administration.
Navigate to the Clusters tab.
Select a cluster.
Choose Permissions from the left panel.

Assign an owner¶

The owner owns the cluster and has all permissions by default.

To assign or transfer ownership:

Select the Owner menu arrow, and then choose a user.
If you are transferring ownership, select Confirm and then Save.

Allow all groups to view the cluster¶

By default, only the owner can see the cluster and choose to use it. You can change this and choose to allow all groups on the instance to view the cluster.

To all groups in the instance to view the cluster:

Select the Usable by all checkbox.
Select Save.

Now you are ready to select groups and assign permissions.

Select groups¶

Select the Select a Group menu arrow, and then choose a group.
Select +Grant Access to Group.
Repeat for each group you want to add.

Dataiku now shows the group you added, along with permission options.

Assign permissions¶

To assign permissions:

Select the checkbox for each permission you want to assign according to the per-resource permissions table, and then select Save to save your changes.

How-to | Assign access to containerized execution ¶

Dataiku can scale most of its processing by pushing down computation to Elastic computation clusters powered by Kubernetes.

In this section, we’ll show you how to restrict which user groups have the right to use a specific Kubernetes execution configuration. By controlling the access to containerized execution through groups, it is possible to define the resources used by different groups within the cluster. This can be useful in a scenario where access to compute-intensive workloads, such as requesting GPUs, large memory, and CPU requests, needs to be limited.

Navigate to the containerized execution settings¶

From the top navigation bar, go to the Applications menu and choose Administration.
Navigate to the Settings tab.
In the left panel, choose Containerized execution.
Select a configuration.

Select groups and assign permissions¶

Under Permissions you can choose whether the configuration is usable by everyone or selected groups. To limit access and choose which groups should have access to this configuration:

Navigate to the Permissions section.
Choose Selected groups.

Dataiku displays group names in a dropdown menu.

Select which groups should have access to this configuration. You may choose one or more groups.
When completed, select Save.

How-to | Assign Deployer infrastructure permissions ¶

The Deployer is the central place in Dataiku to manage bundles and API services from development to production. Only global administrators can create infrastructures such as nodes and deployments. Once an infrastructure is created, you can grant access to an arbitrary number of groups.

In this section, we’ll show you how to grant group access with view, deploy, and admin permissions for infrastructures on the Project Deployer or API Deployer.

Navigate to infrastructure permissions¶

From the Deployer, go to Projects or API Services.
Navigate to Infrastructures.
Select an infrastructure.
Navigate to the Settings tab.
Choose Permissions from the left panel.

Select groups¶

Select the Select a Group menu arrow, and then choose a group.
Select +Grant Access to Group.

Dataiku now shows the group you added, along with permission options.

Assign permissions¶

To assign permissions:

Select the checkbox for each permission you want to assign.
Select the checkbox for each permission you want to assign according to the per-resource permissions table, and then select Save to save your changes.

Code Sample | Add a group to a Dataiku project using Python ¶

You can add a group to a Dataiku DSS Project, and add the ldap authorization group, in Python.

Here is a sample code snippet to achieve this:

import dataiku
client = dataiku.api_client()

client.create_project(name="SAMPLE_PROJECT", project_key="SAMPLE_PROJECT", owner="YOUR_USER")
project = client.get_project("SAMPLE_PROJECT")

project_permissions = project.get_permissions()
project_permissions['permissions'].append({'group':'data_scientists','readProjectContent': True, 'readDashboards': True})
project.set_permissions(project_permissions)

Please note for this snippet, there are two assumptions:

There is a user called YOUR_USER so replace that with a user that actually exists on your instance.
There is a group called data_scientists.

In an Automation node¶

After activating the project in an Automation node, you can edit permissions and give access to the relevant groups.

Specifying which datasets should be included in a project bundle¶

The bundle you create will do so using the project settings. Therefore, before you create it, modify the settings of the project. Depending on whether you use the Python or HTTP rest API, the section to modify is:

project_settings['bundleExporterSettings']['exportOptions']

In order to get there, instantiate the project and modify the settings (obtain settings, then edit the relevant part), see this section of the Developer Guide for an example.

Regarding the exact shape of what you need to enter, you may find it easier to create through the UI, and then inspect the resulting settings of the project in the API. That way, you can modify it programmatically later.

Note

For further information about utilizing the Python APIs, please refer to the following documents:

FAQ | Which activities require that a user be added to the allowed_user_groups local Unix group?¶

When configuring the setup of the local code isolation capability of the User Isolation Framework (formerly known as Multi-User Security), you must fill in the allowed_user_groups settings with the list of UNIX groups to which your end users belong. Only users belonging to these groups will be allowed to use the local code impersonation mechanism.

If you have mixed types of users (data analysts, data scientists, etc.) and aren’t sure which types of Dataiku actions require membership in the allowed_user_groups local Unix group, below is a quick summary.

DO NOT need to be in allowed_user_groups:¶

Users who only run visual recipes on DSS engine, visual recipes on SQL engine, or SQL recipes. For Prepare recipes, they do not use custom Python functions.

DO need to be in allowed_user_groups:¶

Users who run any kind of local code (Python or R - be it in recipes, notebooks, webapps, scenarios, reports, etc.)
Users who run visual ML
Users who run any Spark-powered object (code recipe or notebook, or visual recipe using a Spark engine)

Note

The User Isolation Framework requires an Enterprise Edition license of Dataiku.

To learn more about the User Isolation Framework, visit our reference documentation.

We see above that Dataiku features a set of mechanisms to isolate code which can be controlled by the user, so as to guarantee both traceability and inability for a hostile user to attack the dssuser (the DSS service account). However, the User Isolation Framework is not a single technology, but rather a set of capabilities that permit isolation depending on the context.