Restrict usage of custom plugins to a group of users

NN

Not sure if anyone else has requested this before.
But i was hoping there would be a way to restrict access to a plugin to a certain user group.

I think we can always add a check of the user group in the code itself and raise exception>
But was just wondering if providing a permission tab is something that dataiku is thinking about if its not too much work?

Ashley

Hi @NN
,

Thanks for the idea. Can you tell us a little more about what you have in mind here so that we (and anyone reading your idea) has a better idea of what it would help you do?

What's the use case? Would it be for a specific type of plugin?

Thanks!

Ashley

NN

Hi @AshleyW
,
We developed custom plugins to give a group of users an option to pull data from some external sources.
This data may contain PII information.
There is new group of users whom we plan to add to our existing instance.

We were discussing to see if there is a way to restrict objects to specific groups/
While i can restrict projects, connections and code environments to our first user group.
I couldnt see any option to restrict custom plugins to only one group.

Also like i said before i think we can find a users group and raise exception in the code so i do have a workaround.
But i thought let me float the idea around and see what others think.

Maybe there is way that the plugin recipes will appear disabled to the users who dont belong to the approved group.

Ashley

Hi @NN
,

Thanks for submitting this idea and for sharing the context around why it would be useful to your team. You'll be pleased to hear this idea is in our backlog--being able to restrict access to custom plugin to specific user groups is a request we've received from customers--and we are determining the next steps for development. We can't provide a timeline at this point, but be sure to check back for updates.

For everyone else, kudos the original post to signal that you're interested in Dataiku developing and releasing this feature!

Take care,

Ashley

Turribeach

I agree with Neuron, while it is possible to make the plugin fail if a user doesn't belong to a specific group Dataiku administrators should have the ability to set permissions for plugins in the same way we can do it for folders, projects, connections and code environments.

Tanguy

I suppose implementing this idea would solve this other idea: https://community.dataiku.com/t5/Product-Ideas/Warnings-on-plugins-missing-in-the-Automation-node/idi-p/28242

apichery

Restricting plugins for a group of users does have some non-negligible impacts on projects collaboration and the way DSS has been architectured.

Let's say you have 2 users that have "Write project content" on a DSS project. One (Helen) belongs to the group that can view and use the plugin SuperPlugin. The other (John) is not.

So John cannot add SuperPlugin to the Flow of this project. But Helen can.. and does it.

Now it would mean that John is no longer able to view and execute the Flow of the project while his permissions have not changed. This would lead to a degraded user experience.

Restricting some plugins to some projects might be a more realistic way to solve this request.

Turribeach

Hi @apichery
, thanks for your feedback. I can see the point you make. But actually for a large organisation, like the one I currently work for, your proposed approach will have a worst outcome. In our case the requirement to limit plugin access comes from the fact that certain plugins have limitations in their scability and/or can have detrimental impact on the Dataiku platform or the backend system they connect to. Sometimes we want to limit use of certain plugins as we deemed them not strategic anymore and/or we want to stop their use. However converting existing projects takes time so in the mean time we don't want to have any new projects using the plugin. While your idea of implementing this at project level will allow us that flexibility it would do so at the cost of limiting our business users from self serving and being to use existing plugins on new projects without any assistance from Adminstrators to grant access to plugin A in project B. Obviously if we allow users to add plugins to projects at will this defeat the purpose of having this restriction.

If we use groups to permission plugins we will not need to be in the middle of users wanting to use them. Once they are permissioned users can self serve. If user B doesn't have access to plugin A used in Project C then that's probably intended so it should be fine Whereas with your solution of having an Admin add them to the project it will require some Admin resource.

Finally the issue you raised already applies to code environments as well. Only certain users will have access to certain code environments which will be permissioned by the Groups. So if anything using groups follow the same pattern already used on permissioning folders, projects, connections and code environments by groups. I would expenct the friction in this case to be minimal since our user groups will be defined upfront and will have all the plugin permissions required. So in this scenario (ie large instance) the plugin use will be frictionless.