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

Options
Tanguy
Tanguy Dataiku DSS Core Designer, Dataiku DSS & SQL, Dataiku DSS ML Practitioner, Dataiku DSS Core Concepts, Neuron, Dataiku DSS Adv Designer, Registered, Dataiku DSS Developer, Neuron 2023 Posts: 112 Neuron

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).

112.JPG

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

111.JPG

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

Best Answer

  • Turribeach
    Turribeach Dataiku DSS Core Designer, Neuron, Dataiku DSS Adv Designer, Registered, Neuron 2023 Posts: 1,737 Neuron
    Answer ✓
    Options

    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.

Answers

  • tgb417
    tgb417 Dataiku DSS Core Designer, Dataiku DSS & SQL, Dataiku DSS ML Practitioner, Dataiku DSS Core Concepts, Neuron 2020, Neuron, Registered, Dataiku Frontrunner Awards 2021 Finalist, Neuron 2021, Neuron 2022, Frontrunner 2022 Finalist, Frontrunner 2022 Winner, Dataiku Frontrunner Awards 2021 Participant, Frontrunner 2022 Participant, Neuron 2023 Posts: 1,595 Neuron
    Options

    @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
    Turribeach Dataiku DSS Core Designer, Neuron, Dataiku DSS Adv Designer, Registered, Neuron 2023 Posts: 1,737 Neuron
    Options

    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.

Setup Info
    Tags
      Help me…