Managing Code Environment Permissions: Hiding a Code Environment from Other Users

Tanguy

We have numerous code environments on our Dataiku platform, making it cumbersome to select a specific environment in a notebook from an endless list (see the following image).

We attempted to remove a code environment from this list by unchecking the option "Usable by all" (see the following image).

However, unchecking this option did not affect other users (including those not part of the authorized LDAP groups). Worse, other users could still use the code environment in their notebooks even though it shouldn't have been usable by all!

Is this a bug? If not, how can we exclude certain code environments from the list of kernels in notebooks?

---

Operating system used: RHL

Turribeach

Removing permissions or unchecking the Usable By All on a code env doesn't prevent it's use on existing objects, just on new ones. If you want to remove access from existing objects you will need to do this manually or via the Python API. Or delete the code environment in which case all the notebooks and recipes will fail. This is not different than removing permissions from a connection. Dataiku prefers to prevent the failure so it doesn't impact existing objects. This is not a bug, it's a feature (see here).

Admins and users on groups with the "Manage all code envs" option enabled will be able to use and see all code environments irrespective of the code env permissions. Finally I can confirm that if the user doesn't have permissions then the code environment is not listed as an option for NEW notebooks.

It does seem however that once the notebook is created the user can flip to any kernel regardless of permissions. I have asked Dataiku Support to see what they say.

tgb417

@tanguy

I’m not a regular user of this feature set. We have a very small group on Dataiku DSS.

However, as I was reading this I was wondering if you have put in a support ticket, given that this may be either a defect or feature request. From your description I would agree that I would not expect this feature to operate in that way. I’m sure that there are others who are dealing with the proliferation of code environments so, I invite others to jump in.

Just a thought. As this is a use case that others might find interesting / useful. I invite you to keep the rest of us up to date with your discoveries.

Turribeach

Dataiku Support pointed me to this documentation page which confirms this working as expected:

https://doc.dataiku.com/dss/latest/code-envs/permissions.html

---

The “use” permissions is advisory only. Not having the “use” permission will remove the code env from the list of possible code envs in the various code env selection dropdowns, but does not actually physically prevent you from using the code envs. This is especially true in the notebook where you can change the code env of a kernel.

The “use” permission is mostly used to keep “clean” lists of blessed environments per group.

The underlying binaries of a code env are structurally always readable and knowledgeable users can always use them.

The update / manage permissions are, on the other hand, fully enforced.

---

I suspect that users can easily bypass the code env selector on objects other than Jupyter Notebook kernels by using the Dataiku Python API to set the code env programmatically. I have also noted that there is no way to restrict use of the default/built-in/server code environment which I covered in this Product Idea.

Personally I think Dataiku should enforce code environment access based on the permissions set rather than being "advisory only". If you want to raise a Product Idea I will certainly vote for it.